Re: Proposed HTTP SEARCH method update

Ok. I’ll bite. Why doesn’t DELETE do the same thing?

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

> On May 19, 2015, at 3:08 PM, Wenbo Zhu <wenboz@google.com> wrote:
> 
> 
> 
> On Sun, May 3, 2015 at 11:45 PM, Philippe Mougin <pmougin@acm.org <mailto:pmougin@acm.org>> wrote:
> 
> > Le 10 avr. 2015 à 18:00, James M Snell <jasnell@gmail.com <mailto:jasnell@gmail.com>> a écrit :
> >
> > Please see: http://datatracker.ietf.org/doc/draft-snell-search-method/ <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 <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 <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 <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 <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 <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
>