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

On Wed, Apr 29, 2015 at 9:47 AM, Roy T. Fielding <fielding@gbiv.com> wrote:

> > 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.
>
This looks reasonable, although you mentioned earlier that POST may be made
cacheable too (as controlled by the headers, not the method).

One other worry is the idempotence .. GETs are always safe to retry but
POSTs are not. Or we need clarify that cacheable POSTS are idempotent??

>
> ....Roy
>
>
>