Re: Proposed HTTP SEARCH method update

On Sun, May 3, 2015 at 11:45 PM, Philippe Mougin <pmougin@acm.org> wrote:

>
> > Le 10 avr. 2015 à 18:00, James M Snell <jasnell@gmail.com> a écrit :
> >
> > Please see: http://datatracker.ietf.org/doc/draft-snell-search-method/
> >
> > 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 ("
> http://example.org/feed?q=foo&limit=10&sort=-published") and states: "The
> path identifies the resource processing the query (in this case '
> http://example.org/feed') while the query identifies the specific
> parameters of the search operation."
>
> This description recasts the Web model into an RPC-like system where the
> http://example.org/feed resource is a little bot we send parameters to in
> order for it to perform a search.
>
+1

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
> http://example.org/feed resource involved at all in the search operation.
> The only resource involved is
> http://example.org/feed?q=foo&limit=10&sort=-published. 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
>