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

On 2015-04-29 18:47, Roy T. Fielding wrote:
 > ...
>> 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 may be true for google.*, but is it also the case for every other 
search form we have on the Web?

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

I disagree with the "usually" here...

Anyway, if a search can be scoped outside the request URI, in most cases 
that won't be visible to the routing component you mentioned above. So I 
don't believe that SEARCH makes things worse than they already are.

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

Which makes it interesting to have a way to let the server compute a URI 
template suitable for GET based on a search query (be it POST, SEARCH, 
whatnot)

Best regards, Julian

Received on Wednesday, 29 April 2015 17:02:09 UTC