Re: query language

Just pointing out Open Knowledge at data protocols has collected a small 
list of this kind of query languages over HTTP:

http://dataprotocols.org/data-query-protocol/

Kind regards,

Pieter

On 2014-09-10 18:09, Ryan McDonough wrote:
> If your SLAs and predictable performance matter, I'd be reluctant to 
> offer a service that allowed arbitrary queries to be issued against 
> it. To clarify adhoc, I am referring to the equivalent of being able 
> to issue something like a random SQL query to my service. That's not 
> to say I don't want users to not query my data, but rather I want to 
> control what they can query. For example, HTML forms allows me to 
> control what data sets a consumer can query and the types of 
> operations I want to allow on that resource. I can more predictably 
> determine my SLAs and loads because I'm controlling the data access 
> patterns.
>
> HTSQL (http://htsql.org/) is probably a better example of what I'm 
> getting at. I could create a hypermedia control that generates a query 
> like so:
>
> http://demo.htsql.org/define($avg_credits%20:=%20avg(course.credits))%0A%20.course%7Btitle,%20credits%7D?credits%3E$avg_credits 
> <http://demo.htsql.org/define%28$avg_credits%20:=%20avg%28course.credits%29%29%0A%20.course%7Btitle,%20credits%7D?credits%3E$avg_credits>
>
> If I do that, it could be considered RESTful. But where it starts to 
> violate REST constraints is making the client responsible for 
> constricting links. And requiring the client to have specialized 
> knowledge of how to format these special URIs. Because HTSQL, as well 
> as OData and RQL, have specific URI conventions to issue queries to 
> the server without being instructed by the server as to how to format 
> those URLs, violates a few constraints. To me the violate a lot of Dr. 
> Fielding's clarifications:
>
> http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
>
> Specifically, the 1st, 4th, and last bullet points. Ignoring the  REST 
> constraints, I now loose predicability because clients can issue query 
> work loads that I may not be able to handle. And more importantly, you 
> now have a client/server coupling because the server can't just 
> interpret HTTP URLs, but now needs specialized parsers for HTSQL URLs, 
> or OData URLs, etc. in order to satisfy the request.
>
> Like I said, if I want to offer adhoc query capability, I'd stand up a 
> SPARQL endpoint, likely on different hardware, so that it does not 
> complete with the SLAs of my primary system. But that's just my opinion.
>
> Ryan-
>
> On Wed, Sep 10, 2014 at 11:41 AM, László Lajos Jánszky 
> <laszlo.janszky@gmail.com <mailto:laszlo.janszky@gmail.com>> wrote:
>
>     @Ryan
>
>     Why should a REST service not support adhoc queries? Do this feature
>     violate any of the REST constraints?
>
>     2014-09-10 17:33 GMT+02:00 Ryan McDonough <ryan@damnhandy.com
>     <mailto:ryan@damnhandy.com>>:
>     > I'm with Ruben and wonder what can't be accomplished with Hydra
>     hypermedia
>     > controls? They should able to generate the kind request that you
>     want, and
>     > do so in a more controlled way.
>     >
>     > RQL feels a little like OData in that allows the client to form
>     queries on
>     > their own if they understand the URL conventions. Both RQL and
>     OData enable
>     > the ability to issue adhoc queries to your service. If I wanted
>     to clients
>     > to be able to do that, I'd expose a SPARQL endpoint. OData does
>     this to the
>     > extreme and it's URL conventions is one of my biggest annoyances
>     with OData.
>     > You basically have what people now call "OData URLs" and it
>     requires the
>     > client to understand how to generate OData URLs in order to talk
>     to an OData
>     > server.
>     >
>     >
>     >
>     > Ryan-
>     >
>     >
>     >
>     > On Wed, Sep 10, 2014 at 7:48 AM, László Lajos Jánszky
>     > <laszlo.janszky@gmail.com <mailto:laszlo.janszky@gmail.com>> wrote:
>     >>
>     >> @Erik Wilde Thanks
>     >>
>     >> > http://tools.ietf.org/html/draft-wilde-link-desc-01 might be an
>     >> > interesting thing to look at. the idea is to augment the
>     existing standard
>     >> > of URI template (RFC 6570) in a way that allows services to
>     >> > describe/annotate links.
>     >>
>     >> Thanks! I will check it!
>     >>
>     >>
>     >> @Ruben Verborgh
>     >>
>     >> > What functionality would this offer that the current
>     hypermedia controls
>     >> > in the Core Vocabulary do not?
>     >>
>     >>
>     >> I cannot say, since I don't have it. It would probably result a
>     better
>     >> URI templating mechanism and on service side an automatic URI
>     parsing
>     >> mechanism. Erik might be right, so this should be a separate
>     standard
>     >> instead of part of the Hydra vocab. But I think it should be
>     >> compatible with Hydra, so we could use the already existing class
>     >> definitions by creating and validating the template.
>     >>
>     >
>     >
>     >
>     > --
>     > Ryan J. McDonough
>     > http://www.damnhandy.com
>
>
>
>
> -- 
> Ryan J. McDonough
> http://www.damnhandy.com


-- 

+32 486 74 71 22

Open Knowledge Foundation Belgium
http://okfn.be

Open Transport Working Group OKFN
http://transport.okfn.org