REST 动词 - 哪个约定是“正确的”答案

【问题标题】：REST verbs - which convention is "correct"REST 动词 - 哪个约定是“正确的”
【发布时间】：2010-03-15 14:06:16
【问题描述】：

我很擅长实现 REST 服务（如果重要的话，在 Windows CE 平台上），我开始使用IBM's general definitions 使用 POST 创建（INSERT）和 PUT 进行更新。

现在我遇到了完全相反的Sun's definitions。所以我的问题是，哪个是“普遍接受”的定义？还是有一个？

【问题讨论】：

请将此作为社区 wiki，因为“普遍接受”很难确定。

【解决方案1】：

使用 PUT 创建资源的缺点是客户端必须提供表示它正在创建的对象的唯一 ID。虽然客户通常可以为了生成这个唯一的 ID，大多数应用程序设计人员更喜欢他们的服务器（通常通过他们的数据库）创建此 ID。在大多数情况下，我们想要我们的服务器来控制资源 ID 的生成。那么我们该怎么办？我们可以切换使用 POST 而不是 PUT。

所以：放 = 更新

发布 = 插入

【讨论】：

虽然这提供了一个很好的理由来说明为什么有人可能会使用 Post 进行插入，但它并没有真正将其确立为标准。对于使用 Guid 的任何人来说，id 生成都不是问题。也许正确的答案是没有普遍接受的标准。您可以使用您认为最适合的 HTTP 动词来实现遵守 REST 原则的服务。

【解决方案2】：

使用 POST 作为 INSERT 和 PUT 作为 UPDATE 的原因是 POST 是唯一的nonidempotent 和根据 HTTP 的不安全操作。幂等意味着无论你应用多少次操作，结果总是一样的。在 SQL 中，INSERT 是唯一的非幂等操作，因此它应该映射到 POST。 UPDATE 是幂等的，所以它可以映射到 PUT 上。这意味着相同的 PUT/UPDATE 操作可能会应用多次，但只有第一次会改变我们系统/数据库的状态。

因此，将 PUT 用于 INSERT 将破坏 HTTP 语义，即 PUT 操作必须是幂等的要求。

【讨论】：

不完全正确。如果您查看 Cristian Boariu 的回答。当客户端提供 ID 时使用 PUT 插入时，具有相同 ID 的第二个 PUT 将覆盖新创建的资源，而不是创建新资源。这将使操作保持幂等性。

【解决方案3】：

动词是：

GET {path}：检索标识符为{path}的资源。

PUT {path}：创建或更新标识符为{path}的资源。

DELETE {path}：删除标识符为{path}的资源。

POST {path}：调用一个由{path}标识的动作。

当意图创建一个新资源时，如果我们知道资源的标识符应该是什么，我们可以使用PUT，如果我们希望服务器确定新资源的标识符，我们可以使用POST资源。

【讨论】：

您对 POST 的定义与我链接的两个文档相矛盾。它似乎也表示使用了一个我认为不鼓励使用的动词
你是对的。我的定义与 IBM 和 Sun 的定义相矛盾，因为 IBM 和 Sun 都搞错了。请参阅en.wikipedia.org/wiki/… 的示例和含义表
请注意，GET、PUT 和 DELETE 是标准哈希表（JavaScript 对象、Ruby 哈希、Python 字典）操作。在哈希表上，这些方法都是幂等的。相反，POST 调用在服务上调用复杂方法的图像，而不是在哈希表上执行简单操作。事实上，POST 适用于三个简单哈希表操作（GET、PUT 和 DELETE）不足的所有用例。

【解决方案4】：

当服务器授予客户端对其部分 URI 空间的控制权时，PUT 可用于创建。这相当于在文件系统中创建文件：当您保存到尚不存在的文件时，您创建它，如果该文件存在，则结果是更新。

但是，PUT 缺乏客户端隐含意图的能力。考虑下订单：如果您 PUT 到 /orders/my-new-order 的含义只能是更新由 /orders/my-new-order 标识的资源，而 POST /orders/ 可能意味着“下新订单”，如果POST 接受资源具有适当的语义。

IOW，如果您想在创建新资源的过程中产生任何副作用，您必须使用 POST。

一月

【讨论】：

【解决方案5】：

我们使用 POST= 创建，PUT= 更新。

为什么？没有好的理由。我们必须选择一个，这就是我做出的选择。

编辑。看看其他答案，我意识到关键创建问题可能会做出决定。

我们发布新条目并返回带有生成密钥的 JSON 对象。这似乎更适合普遍接受的 POST 语义。

我们使用标识对象的完整 URI PUT 到现有条目。

【讨论】：

基本上只选择一个然后运行它。我（不经意间）所做的——只是想确保我不会通过选择与常规做法相反的方式来混淆我的所有客户。
“客户”？请更新您的问题，以说明谁可能会感到困惑。
“客户”是指如果我为我的客户（为工作付费的人，而不是服务消费者应用程序）创建此服务，那么他们会继续并希望扩展它并添加更多他们最终不会觉得我对 POST/PUT 的使用与他们作为示例看到的所有其他服务相比是落后的。

【解决方案6】：

这里http://www.w3.org/Protocols/rfc2616/rfc2616.html 是关于如何实现 HTTP 方法行为的官方指南。

【讨论】：

认真吗？你的答案是“阅读整个 HTTP RFC”？它没有讨论 REST 或当今用于实现 RESTful 服务的标准约定。我编写了我正在运行的 Web 服务器，所以我知道 HTTP 是如何工作的。在实现在该服务器上运行的 REST 服务时，我正在尝试使用最佳实践。
不，要了解 HTTP 方法的工作原理，您只需要阅读有关 HTTP 方法的部分：-P。 REST 约束之一，统一接口，基本上意味着当通过 HTTP 进行 REST 时，RFC2616 是你的圣经。也许您正在寻找的是 REST Cookbok，它是一组用于解决 RESTful 系统中常见问题的标准配方。amazon.com/RESTful-Web-Services-Cookbook-Scalability/dp/…

【解决方案7】：

我最近一直在研究 REST 的概念和实现，普遍的共识似乎是：PUT 用于根据资源是否已经存在来创建/更新。 POST 用于将资源附加到集合中。

参见 HTTP/1.1 方法定义http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

POST 旨在允许统一的方法涵盖以下内容功能：
  - Annotation of existing resources;

  - Posting a message to a bulletin board, newsgroup, mailing
    list, or similar group of articles;

  - Providing a block of data, such as the result of submitting a
    form, to a data-handling process;

  - Extending a database through an append operation.
PUT 方法请求将封闭的实体存储在提供的请求 URI。如果 Request-URI 引用了一个已经存在的资源，封闭的实体应该被认为是修改过的驻留在源服务器上的版本。

另请参阅Understanding REST: Verbs, error codes, and authentication 上已接受的问题答案。

【讨论】：