- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Wed, 23 Apr 2014 17:52:50 +0200
- To: <public-hydra@w3.org>
On Wednesday, April 23, 2014 4:38 PM, Thomas Hoppe wrote: > Hi, > > think about the following use-case: You have a collection and you have > the implicit GET based operation to retrieve the the collection > itself (the one we are discussing in parallel is not required to have > a named operation for, Issue #11). Now you want to offer a second > operation which allows querying the collection with some complex > syntax that you don't want to serialize in the query string (maybe it > is too complex to be expressed as URI template). Therefore you define > the operation such that it expects a query object: > > ... > operation: [ > { > @type: "http://example.org/QueryOperation", > method: "GET", > expects: "http://example.org/classes/Query" > } > > So on the server side you are forced to distinguish two GET based > requests. The only way is to consider the request body. Uuhhh... I would really urge you to use a different method. You will probably run into heaps of problems if you use a GET with a request body (even though it is not explicitely disallowed). Why don't you use a PUT instead? In any case, from the point of Hydra is doesn't really matter what method you use. The semantics are expressed by the operation's type (in this case, QueryOperation). The server doesn't see that so it has to "reconstruct" the intention by looking at the request URL and body, as you say. -- Markus Lanthaler @markuslanthaler
Received on Wednesday, 23 April 2014 15:53:16 UTC