- From: Julian Reschke <julian.reschke@greenbytes.de>
- Date: Wed, 20 May 2015 21:49:21 +0200
- To: "Roy T. Fielding" <fielding@gbiv.com>, Phil Hunt <phil.hunt@oracle.com>
- CC: Zhong Yu <zhong.j.yu@gmail.com>, Wenbo Zhu <wenboz@google.com>, Philippe Mougin <pmougin@acm.org>, James Snell <jasnell@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 2015-05-20 19:45, Roy T. Fielding wrote: >> On May 19, 2015, at 9:04 PM, Phil Hunt <phil.hunt@oracle.com> wrote: >> >> What I was trying to illustrate is that DELETE is also a function and it hasn’t turned the web into RPC. Why have RPC methods like PATCH PUT and DELETE? > > They are not RPC methods. They have uniform semantics, operate on the target resource, > and are defined in such a way that intermediaries can understand their intended effects. > >> I don’t see how SEARCH “hurts” the web. If GET is supposed to be a web linkable resource and not one with embedded RPC functions like SEARCH or for that matter delete (e.g. GET http://example.com/Users/123?method=delete). In a hypermedia web, don’t we want to keep GET from being overloaded with functions like search? > > SEARCH does not have uniform semantics (it means different things based on the body), > does not operate on the target resource, and is useless for intermediaries. It has the same properties as PATCH wrt the payload. Whether it operates on the target resource seems to be a matter of definition and opinion. > However, that isn't why it is bad for the Web. > > The reason SEARCH is bad for the Web is because it allows lazy fools to provide > reusable information in a form that doesn't have an associated resource identifier. > It provides the same function as a parametrized GET request without minting a URL. > In other words, it reduces the number of identifiable resources, which reduces > the network effect of linked resources, which harms the Web because it reduces the > power of the resulting information system. Which is why the spec should recommend that a SEARCH response comes with a Content-Location whenever feasible. Best regards, Julian
Received on Wednesday, 20 May 2015 19:49:53 UTC