在REST API设计中查找或创建成语？

Question

假设我们有'用户'资源，对'name'有唯一约束。您将如何设计REST API来处理find-or-create（按名称）用例？我看到以下选项：

选项1：多个请求

客户：

POST /user
{"name":"bob"}

服务器：

HTTP 409 //or something else

客户：

GET /user?name=bob

服务器：

HTTP 200 //returns existing user

选项2：一个请求，两个响应代码

客户：

POST /user
{"name":"bob"}

服务器：

HTTP 200 //returns existing user

（如果实际创建了用户，则返回HTTP 201）

选项3：请求错误但响应数据包含冲突的实体

客户：

POST /user
{"name":"bob"}

服务器：

HTTP 409 //as in option1, since no CREATE took place
{"id": 1, "name":"bob"} //existing user returned

Answer 1

我相信这种“正确”的RESTful方式是：

GET /user?name=bob
   200: entity contains user
   404: entity does not exist, so
        POST /user { "name" : "bob" }
           303: GET /user?name=bob
                200: entity contains user

我也是Post-Redirect-Get模式的忠实粉丝，这需要服务器使用新创建的用户的uri向客户端发送重定向。然后，您在POST情况下的响应将使其实体在其正文中具有状态代码200。

这意味着要经过1次或3次往返服务器。 PRG的一大优势是在发生页面重新加载时保护客户端免于重新发送，但您应该阅读更多有关它的信息，以确定它是否适合您。

如果这与服务器来回过多，你可以做选项2.我对https://tools.ietf.org/html/rfc2616#section-9.5的阅读不是严格的RESTful：

POST方法执行的操作可能不会生成可由URI标识的资源。在这种情况下，200（OK）或204（No Content）是适当的响应状态，具体取决于响应是否包括描述结果的实体。

如果你没有偏离标准，并且你关心往返，那么选项2是合理的。

Answer 2

我使用的是选项2的版本。我在创建资源时返回201，而仅在检索资源时返回303 ("see other")。我选择这样做，部分原因是因为get_or_create似乎不是常见的REST习惯用法，而303是一个稍微不同寻常的响应代码。

Answer 3

我会选择选项2，原因有两个：

首先，HTTP响应代码2xx（例如200第201）指的是与4xx不同的成功操作。因此，在发现或创建发生的两种情况下，您都可以成功运行。

其次，选项1将对服务器的请求数量加倍，这可能是重负载的性能损失。

Answer 4

我相信一个GET请求：

• 返回现有记录;要么
• 创建一个新记录并返回它

是我在这里回答的最有效的方法：Creating user record / profile for first time sign in

服务器需要在响应中返回之前创建记录是无关紧要的，正如@Cormac Mulhall和@Blake Mitchell在REST Lazy Reference Create GET or POST?中所解释的那样。

这也在Section 9.1.1 of the HTTP specification中解释：

当然，不可能确保服务器不会因执行GET请求而产生副作用;实际上，一些动态资源会考虑这个功能。这里的重要区别是用户没有请求副作用，因此不能对他们负责。