Re: query language

> using POST in this case because GET has the issues with not being very request-body-friendly

POST would violate the cache constraint, and it is possibly against
the HTTP method definitions, since GET is for data retrieval.

> very complex requests at some point often do not even fit into URIs anymore.

I have serious doubts about this. AFAIK I need more than 1000
characters to exceed the max length of query strings. Currently by URI
templates even simple nested statements are not supported...

> not every problem needs to be hammered with the same hammer. if you have complex and maybe even domain-specific ways how you interact with a resource, create your own media type for it that supports these interactions.

I fail to see why should I create an own media type, since I cannot
send body with a GET request.


2014-09-10 19:53 GMT+02:00 Erik Wilde <dret@berkeley.edu>:
> hello lászló.
>
> On 2014-09-10, 10:38 , László Lajos Jánszky wrote:
>>
>> Actually this is somebody elses need in a forum, I am just
>> investigating. Well there is a possible scenario: the client wants to
>> search items from a collection with complicated conditions (which can
>> use and, or, not, etc... operators). How would you support such a
>> feature?
>
>
> not every problem needs to be hammered with the same hammer. if you have
> complex and maybe even domain-specific ways how you interact with a
> resource, create your own media type for it that supports these
> interactions.
>
>> Since this is a retrieval request it is obvious, that it should use
>> GET and send the details in the query of the URI (since they are not
>> necessary hierarchical). So we need a query language to describe this
>> kind of conditions. It can be RQL, but it can be any other query
>> language we can serialize and send in the URL. But maybe I am missing
>> something... Do you have a better solution?
>
>
> very complex requests at some point often do not even fit into URIs anymore.
> at which point you get to the interesting question of whether it's even
> legal to send GET requests with a request body...
>
> http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html
>
> but regardless of these specific HTTP questions: if you have complex
> requirements for how clients and servers should interact, then trying to
> cover all of these with a generic language at some point in time may become
> a bad idea.
>
> instead, loosely couple things and add a hint that tells clients that when
> interacting with a resource, they need to understand the specific way in
> which that resource accepts requests. we needed something like this for LDP,
> and as a result there is a proposal for Accept-Post, which is an HTTP-based
> way of how a client can learn about the fact that a resource accepts a
> specific media type (using POST in this case because GET has the issues with
> not being very request-body-friendly):
>
> http://tools.ietf.org/html/draft-wilde-accept-post-02
>
> this might be a good way to loosely couple a general interaction framework
> such as hydra, while still allowing more specific interaction forms that can
> be arbitrarily complex. this Accept-Post information could also be embedded
> in a link description (again, just as a hint), so that clients would know
> how to interact.
>
>
> cheers,
>
> dret.
>
> --
> erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
>            | UC Berkeley  -  School of Information (ISchool) |
>            | http://dret.net/netdret http://twitter.com/dret |

Received on Wednesday, 10 September 2014 18:22:46 UTC