rest - 是否需要 DELETE/PUT http 动词？

Question

我看不出设计一个使用 PUT 和 DELETE 来更新和删除数据的 REST API 服务有什么巨大好处。可以使用 POST 和唯一的 url 轻松替换这 2 个动词。

我看到使用 PUT 和 DELETE 的唯一好处是它减少了 REST API 服务使用的 url 的数量，这并不多。还有其他我忽略的好处吗？

Answer 1

这实际上与 REST 关系不大，而与超文本传输​​协议(protocol) (HTTP) 关系更大。

HTTP 的基本思想是您对特定资源(由其 URL 标识)执行特定操作(HTTP 方法之一，例如 GET、POST、PUT 和 DELETE)。因此，如果您通过将操作添加到 URL(例如 http://example.com/api/books/123/delete)并使用不同的 HTTP 方法来偏离它，那么您就违反了 HTTP 协议(protocol)。

它的缺点可能不会立即显现(因为它仍然有效)，如果您只是自己使用 API，则可能会受到限制。但是，如果其他程序员也在使用该 API，则您声明自己拥有 RESTful HTTP API 而实际上并未遵守该协议(protocol)，这就是在制造某些期望。

例如，如果调用 GET/api/books/123 返回图书资源的表示，开发人员希望能够在同一 URL 上调用 PUT更新那本书的信息，然后 DELETE 一起删除这本书。 (当然，如果他没有这样做的权限，你实际上并没有删除这本书，但你返回了 403 'Forbidden' 或 405 'Method Not Allowed' 状态代码——这也是 HTTP 规范的一部分)

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

Darrel Miller 在他的回答中提出了另一个很好的观点。 HTTP方法都有一定的意义，也有一定的特点。例如，GET 应该是一个安全方法，用于在服务器端不做任何更改的情况下检索信息。并且 PUT 和 DELETE 是幂等，这意味着(即使它们不像那样安全方法GET) 你可以发出任意多的请求而没有任何不必要的副作用(删除一本书一次或十次具有相同的效果:这本书不见了)。然而，POST 不是幂等的:如果您执行十次 POST 请求来创建一本新书，您很可能最终会得到 10 个重复的书籍条目。

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

所以长话短说:使用协议(protocol)或标准(例如 HTTP)设定了特定的期望，如果您随后偏离协议(protocol)，您将产生意想不到的行为和可能不需要的副作用。