Re: QUERY Verb Proposal

We could define a link header that pointed to query specification.
Then we could use this header on a GET.

All the best, Ashok

On 1/20/2015 3:27 AM, henry.story@bblfish.net wrote:
>> On 20 Jan 2015, at 01:36, Sandro Hawke <sandro@w3.org> wrote:
>>
>> On 01/19/2015 05:30 PM, ashok malhotra wrote:
>>> Sandro, some questions inline ...
>>>
>>> All the best, Ashok
>>>
>>> On 1/19/2015 5:19 PM, Sandro Hawke wrote:
>>>> I suggest the spec say how to do it with GET as well as QUERY, and what exactly the differences are.
>>> Sorry, how would you do it with GET?  Are you talking about stored queries?
>> Even with not-stored queries, you can still just turn them into a GET, right?   (assuming the query is under 2k, at least, although that IE limit might not apply to LDP situations)
>>
>> One simple design:
>>
>> 1.  Do a HEAD
>> 2.  Response includes Link: <http://q.example> rel=query-via
>> 3.  GET http://q.example?r=url-of-original-resource&t=query-type&q=your-query
>>
>> It's approximately the interchange you'll need with QUERY:
>>
>> 1.  Do a HEAD
>> 2.  Get back some response saying QUERY is supported
>> 3.  QUERY url-of-original resource, body=your query
>>
>> One of the reasons the HTTP WG is very unlikely to standardize this is that there's so little technical advantage to doing this with a new verb (at least as far as I can see).   The main reasons would be queries > 2k, but your saved queries solve that, and allowing intermediate nodes to understand and cache based on query semantics, ... and MAYBE the Get option would allow that.
> Some of the disadvantages of your approach I can think of at present:
>
> • Queries are limited to < 2k
> • URLs are no longer opaque. You can see this by considering the following:
>     - if a cache wants to use the query URL to build up a partial representation of
>     the original document, it would need to parse the query URL. So we end up with mime
>     type information in the URL.
>     - If the cache sees the query URL but does not know that the original resource
>     is pointing to it, then it cannot build up the cache ( and it cannot know this
>     without itself doing a GET on the original URL, because otherwise how would it deal
>     with lying resources that claim to be partial representations of other URLs? )
> • URL explosion: one ends up with a lot more URLs - and hence resource - than needed,
>    with most resources being just partial representation of resources, instead of
>    building up slowly complete representation of resources.
> • caching
>    - etags don't work the same way on two resources with two URLs as with one
>      and the same URL
>    - the same is true with time-to-live etc.
>    - A PUT, PATCH, DELETE on the main resource won't tell the cache that it should
>      update all the thousand of other resources that are just views on the
>      original one
>    - The cache cannot itself respond to queries
>       A cache that would be SPARQL aware, should be able to respond
>       to a SPARQL query if it has received the whole representation of the
>       resource already - or indeed even a relevant partial representation )
>       This means that a client can send a QUERY to the resoure via the cache
>       and the cache should be able to respond as well as the remote resource
> • Access Control
>      Now you have a huge number of URLs referring to resources with exactly the same
>      access control rules as the non query resource, with all that can go wrong, when
>      those resources are not clearly linked to the original
> • The notion of a partial representation of an original resource is much more opaque
>    if not lost without the QUERY verb. The system is no longer thinking: "x is a partial
>    representation of something bigger, that it would be interesting to have a more complete
>    representation of"
>     
> Btw. Do we have a trace of the arguments made in favor of PATCH. Then it would be a case
> of seeing if we can inverse some of those arguments to see if we are missing any here.
>
>> BTW, all my query work these days is on standing queries, not one time queries.  As such, I think you don't actually want the query results to come back like this.   You want to POST to create a Query, and in that query you specify the result stream that the query results should come back on.  And then you GET that stream, which could include results from many different queries.   That's my research hypothesis, at least.
>>
>>        -- Sandro
>>
>>>> Assume the HTTP WG will say no for the first several years, after which maybe you can start to transition from GET to QUERY.
>>>>
>>>> Alternatively, resources can signal exactly which versions of the QUERY spec they implement, and the QUERY operation can include a parameter saying which version of the query spec is to be used. But this wont give you caching like GET.   So better to just use that signaling for constructing a GET URL.
>>> Gimme a little more to help me understand how this would work.
>>>>        -- Sandro
>>>>
>>>>
>>>
>>
> Social Web Architect
> http://bblfish.net/
>

Received on Tuesday, 20 January 2015 13:29:42 UTC