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

[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 18:53:16 UTC