需要使用DELETE/PUT HTTP动词吗？

Question

我认为设计一个使用PUT和DELETE来更新和删除数据的REST API服务并没有太大的好处。这两个动词可以很容易地被一个POST和唯一的URL所替代。

我唯一能看到使用PUT和DELETE的好处是减少了REST API服务使用的URL数量，但这并不多。我是否忽视了其他好处？

- burnt1ce

---

当您从REST模式切换到通过POST将所有内容隧道传输到单个端点时，您正在从基础设施完全使用的众所周知的协议切换到基础设施无法使用的特定协议。当HTTP和REST对于您的底层API非常不适合以至于您感觉别无选择时，请开始朝着通过POST隧道传输特定协议的方向发展。 - MatthewMartin

Answer 1

这实际上与REST关系不大，更多的是与超文本传输协议（HTTP）有关。

HTTP的基本思想是对某个资源（通过其URL标识）执行某个操作（HTTP方法之一，如GET、POST、PUT和DELETE）。因此，如果您开始将操作添加到URL中（例如http://example.com/api/books/123/delete）并使用不同的HTTP方法，则违反了HTTP协议。

这样做的缺点可能不会立即显现（因为它仍然可以工作），如果其他程序员也在使用API，那么您正在创建某些期望，声称您拥有符合RESTful HTTP API标准的API，而实际上您并未遵守该协议。

例如，如果调用GET /api/books/123返回书籍资源的表示形式，则开发人员期望能够在同一URL上调用PUT以更新有关该书籍的信息，并使用DELETE从中删除该书籍。 （当然，如果他没有权限这样做，您实际上不会删除该书籍，而是返回403“禁止”或405“方法不允许”的状态代码-这些也是HTTP规范的一部分）

但是，如果您偏离协议（基本上发明自己的协议），则必须在某个地方描述，开发人员必须调用POST /api/books/123/remove/the/book而不是DELETE /api/books/123。他们必须了解您API的所有自定义规则，因为您没有遵循标准。

另一个好的观点是Darrel Miller在他的回答中提出的。HTTP方法都有一定的含义和特点。例如，GET应该是一种“安全方法”，用于检索信息而不对服务器端进行任何更改。而PUT和DELETE是幂等的，这意味着（尽管它们不像GET那样是“安全”方法），您可以随意发出多个请求而没有任何不必要的副作用（删除一本书一次或十次具有相同的效果：书被删除）。然而，POST不是幂等的：如果您执行十个POST请求来创建一本新书，您很可能会得到10个重复的书目录。

由于这些特性，开发者和工具可以做出某些假设。例如，搜索索引器（如Googlebot）只会进行GET请求，以避免在服务器上破坏任何东西。但是，如果您违反HTTP规范，例如使用URL http://example.com/api/books/123/delete 来删除一本书，您可能会注意到有一天您的数据库完全为空，因为Google一直在索引您的网站。那不是Google的错，而是您的错，因为您没有遵循规范。

所以长话短说：使用协议或标准（如HTTP）会产生某些期望，如果您偏离了协议，就会创建意外行为和可能的不良副作用。

- Nic Wortel

---

那么“HTTP只是在URL标识的某个资源上执行的某个操作”？这听起来像是一个非常狭窄的概述，留下了很多情况。我认为这不是“HTTP的基本思想”。这是REST的基本思想。HTTP的基本思想是请求和响应。资源和操作是要实现的抽象。 - Gherman

Answer 2

不一定需要使用PUT和DELETE方法才能获得REST系统的好处。在某些情况下，使用更精确的方法可能是有利的。通常是中间组件利用这些语义。PUT和DELETE是幂等方法，因此如果某个通用组件收到503响应，理论上它可以重试PUT/DELETE直到获得成功的响应。对于POST方法，中间件无法做到这一点。使用DELETE方法时，客户端知道不发送主体。使用PUT方法，它知道要发送完整的表示形式。对于POST方法，您需要以其他方式（如链接关系）向客户端传达如何进行请求。

- Darrel Miller

Answer 3

您可以不使用PUT和DELETE。

本文告诉您为什么: http://www.artima.com/lejava/articles/why_put_and_delete.html

但是（引用自Fielding）：“REST API不应该包含除填充或修复标准协议的细节之外的任何通信协议更改，例如HTTP的PATCH方法或Link头字段。针对已损坏实现的解决方法（如那些愚蠢到相信HTML定义了HTTP的方法集的浏览器）应单独定义，或者至少在附录中定义，并期望这种解决方法最终会过时。[在这里失败意味着资源接口是特定于对象而不是通用的。]”(http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven)

- Gabe