Re: Proposed HTTP SEARCH method update - QUERY is to GET what PATCH is to PUT

> On Apr 28, 2015, at 11:02 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2015-04-28 22:52, Roy T. Fielding wrote:
>>> On Apr 28, 2015, at 11:57 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
>>> 
>>> On 2015-04-28 18:29, Roy T. Fielding wrote:
>>>> ...
>>>> That is scoping by the message body, not by the method semantics.  The difference is
>>> 
>>> Yes.
>>> 
>>>> that the request target contains essential bits for routing a request within (or behind)
>>>> the origin server, so if a special route is applied to, for example, a path within the
>>>> URI, then we want the method semantics to be limited to the scope of that path.
>>>> If the scope is not limited by the method, then implementation gets very messy.
>>>> [POST might have remained limited in that way as well, but the introduction of forms
>>>> made its original semantics irrelevant, so there wasn't much point in scoping them.]
>>> 
>>> I agree with the explanation, but exactly how is this different from how a GET on a search engine works?
>> 
>> Because a GET has all of the information necessary to see the scope
>> within the request target.
>> 
>> ....Roy
> 
> Hm, no.
> 
> Example: <https://www.google.de/search?q=site:ietf.org+roy>

The www.google.de origin server (including the network of gateways that are configured
to handle its requests) knows that its /search engine is scoped to the entire Web.
It even knows what site: means within the query syntax.

This is fundamentally different from the scope being specified within the body
because the body is not usually read until after the request has been routed and
most access control has been settled.

It is, of course, possible to interpret anything in a message at any time.
It just gets messy.

Regardless, I would not want to implement SEARCH as either a generalized query interface
(a la WebDAV) or as a query on the representation that one might have received from a GET.
We have one primary method for retrieval because having a URI is the sugar that the rest
of the system needs.  Sub-resources can be identified and retrieved directly by form,
script, template, or a single level of indirection (e.g., search results).  A smart
implementation can reduce common query parameters on the client-side so that the URI
produced is much smaller than whatever the user may have typed.  Queries that actually
require 2kB of search parameters can use POST -- a cache cannot key them anyway.  

....Roy

Received on Wednesday, 29 April 2015 16:47:48 UTC