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

假设我们有'用户'资源,对'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

Eric Stein.. 11

我相信这种"正确"的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是合理的.