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

Roy:
Consider a collection of books.  The collection has a URI
and each book has a URI and there may be link relations between
the collection and each book.  But sometimes, I want to find books
by title or author or ISBN instead of following links.
This is the usecase I am getting from several sources.

Would changing the name of the verb help?

All the best, Ashok

On 4/27/2015 2:52 PM, Roy T. Fielding wrote:
> [resending from the right address]
>
>> On Apr 27, 2015, at 1:52 AM, henry.story@bblfish.net wrote:
>>
>>> On 27 Apr 2015, at 08:59, Julian Reschke <julian.reschke@gmx.de> wrote:
>>>
>>> On 2015-04-27 07:36, henry.story@bblfish.net wrote:
>>>> ...
>>>> It would help if you explained how you disagree with the arguments put forward.
>>>> Let's try the Socratic method then:
>>>>
>>>> (1) Do you agree that SEARCH is (should be) a method that is applied to the resource on which the request is made?
>>>
>>> Depends on the definition of "applied". You might want to read <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.2.2.1>.
>>
>> I suppose I don't find that notion of "search arbiter" very satisfying in WebDAV. It is defined just as "A resource that supports the SEARCH method". My feeling is that by specifying SEARCH more generally in its own RFC we could do a lot better than this, and have something that ties in more coherently with the other methods. This is why I'd like to strengthen the following parallel: SEARCH is to GET what PATCH is to PUT. If we can get this to work then we build on very well understood intutions of GET and PUT, which are at the core of the Web, in a clearly RESTful manner.
>
> The original SEARCH method was removed from HTTP in 1994 because it discouraged
> the use of identifiers for important resources. In short, it weakened the Web.
>
> What MS implemented as SEARCH [1] and WebDAV defined (in RFC5323) was a really bad idea
> for a site-wide query interface, along the same bad taste lines as service endpoints
> for web services.
>
>   [1] https://msdn.microsoft.com/en-us/library/aa143053%28v=exchg.65%29.aspx
>
> In both of those definitions, SEARCH was not a method that scoped its results to the requested
> URI.  That URI, in fact, had almost nothing to do with the results, making implementation
> of the method a significant security risk.
>
> Neither of those were RESTful in any sense of that term.  Regardless, the method was defined
> and registered as such for HTTP (which is not limited to RESTful interaction), and there is
> no reuse of method names allowed in HTTP.  You need to use a new method name if you want to
> define a method with different semantics.
>
> In any case, it remains true that generalized retrieval in the form of a method other
> than GET would be actively harmful to the Web.  Partial query within the scope of the
> current representation of a single resource is a very distinct concept that, if defined,
> ought to have a distinct method name.  However, I would still consider that a bad idea,
> since it is a loss in every way when compared to a link template to sub-resources.
>
> BTW, HTTP defines caches based on the generic method/response relationship, not based on the
> GET/representation relationship.  It is possible to cache responses to arbitrary methods if
> the response indicates it is cacheable.  What is difficult is how to determine the cache key
> for a given request, which HTTP only defines only for GET and for responses containing the
> Content-Location header field (new methods would have to define their own cache keys).
> Generic HTTP caches only implement for GET/HEAD because the likelihood of receiving a
> later hit on a cached entry for anything other than GET is so ridiculously tiny that it isn't
> worth caching outside of application-specific client caches (for which generic semantics
> are usually irrelevant because the application can be tightly coupled to the cache).
>
>
> Cheers,
>
> Roy T. Fielding                     <http://roy.gbiv.com/>
> Senior Principal Scientist, Adobe   <http://www.adobe.com/>
>

Received on Monday, 27 April 2015 20:35:25 UTC