Re: query language

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

We are talking about the exact same thing: How to describe the query
parameters and appliable condition structures which can be used to
build, validate and process an ad-hoc query... We need standards for
this if we want to support search in REST APIs...

> I now loose predicability because clients can issue query work loads that I may not be able to handle.

That's why you have to describe what your API is able to handle and
send this information with the search links.

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

I don't think this would be any different than supporting another MIME
type. So I don't think this means lose coupling, since these are
standards, and not custom application specific things.



2014-09-10 18:09 GMT+02:00 Ryan McDonough <ryan@damnhandy.com>:
> 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

Received on Wednesday, 10 September 2014 17:57:09 UTC