[oslc-core] Search via POST vs. AtomPub-style collections

[Andrew J Berner]

Andy Berner
Lead Architect, ISV Technical Enablement and Strategy
IBM Rational Business Development
972 561-6599
ajberner at us.ibm.com

Ready for IBM Rational software partner program -
http://www.ibm.com/isv/rational/readyfor.html

Dave wrote:

> > Currently, in the Core spec we allow a query resource to be requested
> > via HTTP GET with the search terms specified in the query string of
> > the URI. We also allow search via HTTP POST to the query base URI,
> > where the search terms are specified in form-encoded key/value pairs.
> >
> > Problem is, this conflicts with the simple AtomPub-style model where
> > you have one URL for a collection, you POST to that collection to
> > create new entries and you GET from URL to get a listing of the
> > entries. Query by POST doesn't necessarily rule out the AtomPub-style
> > model, but it makes the implementation a little kludgey. When you have
> > a POST coming in, you have to examine the content-type; if its form
> > encoded data you have to return a query, if it is anything else you
> > have to create a new resource.

The GET (to read) vs POST (to add to) for a collection makes sense for a
resource that's a collection.  But while a query "sort of" is a resource
that's a collection, it's actually a read-only list of answers to a
question.  It in general won't make sense to "add" to a query.

Since the query base is specifically labeled as such, it should be clear to
the client.

Now, the "query by POST" gets around the potential (notice I say
"potential" and we could debate how real it is) that the query needs a long
list of attributes in the various clauses, and those attributes have long
names, so you run into the limit of URL length:  URL query strings in GET
calls are not intended to have arbitrarily long lists like you need for
queries.

So the fact that many current OSLC uses are primarily delegated UI doesn't
mean we won't have a lot of server to server OSLC integrations that need
detailed queries, and we may want to determine the meaning of "POST to the
query base" now, even if some implementations don't bother implementing it
right away.