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

[Scott Bosworth]

Dave, the pattern you are trying to promote/allow for here makes a lot of
sense to me as the simplest (and perhaps most common) way that
ServiceProviders are defined. I can see this especially in cases where
Query syntax is not fully employed but the querybase is just used to GET
the full list of resources. So, I add to the list by POST and retrieve the
list with a GET request to the same URI.

I worry that the POST query will be overlooked by many service provider
implementations. The fact that we have a spec topic with few or any
implementations indicates to me that we got a bit ahead of ourselves and
our principle of specifying only the minimum to support key use cases. That
said, it seems reasonable that (as Andy and Nick have pointed out) long
query strings are a realistic issue to deal with. Are there other
alternatives to the POST query approach? If we can see a way to another
solution in the future, then I agree that stepping back from the current
approach is, in balance, a good thing to do....Scott

oslc-core-bounces at open-services.net wrote on 03/21/2011 01:45:15 AM:

> From: Nick Crossley/Irvine/IBM at IBMUS
> To: oslc-core at open-services.net
> Date: 03/21/2011 01:45 AM
> Subject: Re: [oslc-core] Search via POST vs. AtomPub-style collections
> Sent by: oslc-core-bounces at open-services.net
>
> I agree that the POST query is important for long queries.  While
> there may not be any implementations
> that support such queries today, that may well change soon as people
> start to add more complex clients
> and integrations using OSLC.  Queries from a central index using the
> Change Log service currently
> under discussion may need to be long and complex, to query against
> differently named or valued
> properties in the different service providers contributing to an index.
>
> Nick.
>



Scott Bosworth | IBM Rational CTO Team | bosworth at us.ibm.com | 919.486.2197
(w) | 919.244.3387(m) | 919.254.5271(f)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110321/d77ecdf9/attachment-0003.html>