- From: Philippe Mougin <pmougin@acm.org>
- Date: Mon, 4 May 2015 08:45:12 +0200
- To: James M Snell <jasnell@gmail.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> 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.
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
Received on Monday, 4 May 2015 06:45:36 UTC