Re: query language

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

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> 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>:
> > 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> 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