Re: Proposed HTTP SEARCH method update

On Sun, May 3, 2015 at 11:45 PM, Philippe Mougin <> wrote:

> > Le 10 avr. 2015 à 18:00, James M Snell <> a écrit :
> >
> > Please see:
> >
> > Comments welcome.
> >
> > - James
> >
> James,
> I think the introduction chapter fails to correctly characterize the way
> GET is commonly used to support search operations.
> The draft gives an example ("
>") and states: "The
> path identifies the resource processing the query (in this case '
>') while the query identifies the specific
> parameters of the search operation."
> This description recasts the Web model into an RPC-like system where the
> resource is a little bot we send parameters to in
> order for it to perform a search.

SEARCH with a body feels as bad as "X-HTTP-Method-Override" alike (when one
has to work around the URL encoding limit to turn a GET into POST), and
neither will be safely retried or cached, yet.

GET with a body: to ensure no server will ignore the body, could we expect
the client to generate a unique token in the URL? Also, I think the C-T
alone will be sufficient to categorize a GET as a search request, by
supported proxies/servers.

> But this is not the case. Actually with the GET approach there is no
> resource involved at all in the search operation.
> The only resource involved is
> Typically this
> resource will be defined as being the result of a specific search
> computation (or might be defined in more abstract terms).
> This is one of the distinctive feature of the Web: the ability to define
> ressources as the results of some computations and to perform these
> computations when a client GET the representations of these resources. This
> has numerous implications such as the existence of a generic retrieval
> method, the  ability to support hypermedia by linking to these resources
> (e.g., a link to the next page of a large search result set), and the
> ability to support caching of computations' results.
> SEARCH, on the other hand, does not make use of this approach. A sensible
> comparison of SEARCH and GET should take this difference into account, I'd
> suggest.
> Best,
> Philippe Mougin

Received on Tuesday, 19 May 2015 22:09:09 UTC