Re: QUERY Verb Proposal

James:
If we went down the path of rewriting RFC 5232 to work over HTTP
as you suggested in your last email, what would the standardization
process be?

All the best, Ashok

On 1/20/2015 11:18 AM, James M Snell wrote:
> On Tue, Jan 20, 2015 at 12:27 AM, henry.story@bblfish.net
> <henry.story@bblfish.net> wrote:
> [snip]
>> 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.
>>
> Better yet, you have one of the co-authors of that spec ;-). Many of
> the arguments for and against PATCH likely wouldn't really apply here.
> Those really did not deal with the opacity of the request URI, access
> control, etc. In fact, the only significant argument against PATCH
> that I can recall is that, at the time, much of the existing HTTP
> infrastructure was not very well suited for handling new HTTP methods.
> There are still some popular platforms (such as Node.js) that refuse
> to support extension HTTP methods unless there is a standards track
> RFC defining them. (this would be one of the arguments in support of
> using SEARCH over QUERY, btw). The other key issue for PATCH was the
> lack of standardized patch formats (which is less of a problem today
> but there still aren't many). For QUERY/SEARCH, this is far less of an
> issue. QUERY would have a more difficult time passing IETF review and
> being implemented consistently but SEARCH could possibly bump up
> against WebDAV support in existing stacks. With either, there are
> plenty of query formats available that we can leverage.
>
> The issue of caching the results of a QUERY/SEARCH is significant. The
> operation would not be idempotent and Vary only works with request
> headers. Given two identical QUERY/SEARCH requests sent one after the
> other, we can likely expect very different results. Doing a GET on the
> same URI would likely return a different result entirely. If the
> results of a QUERY/SEARCH are to be cached, I would argue that the
> response ought to be REQUIRED to contain a Content-Location header
> identifying a location where the same results can be fetched using a
> GET but even that is not entirely trustworthy. We'd have to play
> around with this a bit to make sure we get it right.
>
> - James
>
>>> 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 16:40:10 UTC