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 [email protected] wrote on 03/21/2011 01:45:15 AM: > From: Nick Crossley/Irvine/IBM@IBMUS > To: [email protected] > Date: 03/21/2011 01:45 AM > Subject: Re: [oslc-core] Search via POST vs. AtomPub-style collections > Sent by: [email protected] > > 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 | [email protected] | 919.486.2197 (w) | 919.244.3387(m) | 919.254.5271(f)
