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

[Dave]

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. We might want to come up with a design
different from what we have now.

I've done a little asking around and it appears that OSLC query by
POST is not implemented and not really needed for any of our use
cases. So, what I would like to propose is we remove Query by POST
from the Core spec, and deal with this issue in a future spec
revision.

Does anybody have objections to this?

Thanks,
Dave