Re: query language

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 17:53:58 UTC