Question

我正在创建一个RESTful API，用于创建强制使用唯一电子邮件地址的用户：

成功POST /users：HTTP 201 Created

如果我POST再次使用相同的电子邮件地址，响应代码应该是什么？ 409 Conflict是否是相应的响应代码？

Answer 1

是的，409是最合适的响应代码。即使你最有可能在成功时返回201，你仍然会发布到一个被描述为集合的资源，而POST一个重复的电子邮件肯定是与“资源的当前状态”作为集合的冲突。如果可能，您应该返回一个包含问题描述的响应正文和超链接，以帮助解决问题。

Answer 2

我对返回现有注册电子邮件的409 Conflict并不满意-我认为这不是客户错误。因此，让我们看一下一些大型科技公司是如何处理这种情况的（至少他们是如何在其WEB网站API中做到这一点的。）

Gmail（Google）返回一个200 OK和一个JSON对象，其中包含一个代码，该代码指示该电子邮件已被注册。

Facebook 还返回了200 OK，但将内容重新呈现到了恢复页面，以使用户可以选择恢复其现有帐户。

Twitter 正在通过AJAX呼叫验证现有电子邮件到另一个资源。电子邮件验证资源的响应始终为200 OK。响应包含一个JSON对象，该对象包含一个标志，用于指示电子邮件是否已注册。

Amazon 的做法与Facebook相同。返回200 OK并将内容重新呈现到通知页面，以通知用户该帐户已存在，并为他/她提供采取进一步操作（如登录或更改密码）的可能性。

因此，所有这些API总是返回200 OK并向客户端/用户显示其他内容以恢复其帐户，或者向响应的正文内容显示一条错误消息。

Answer 3

虽然接受的答案在显示任务的正确状态代码时是正确的，但我想补充一点，即您引入了一个安全漏洞。

如果您返回409进行帐户注册，则只需公开帐户枚举服务。

取决于申请，如果api是否公开等，即使未创建帐户，您也可能希望返回201.

Answer 4

+1给Barts答案 - 出于安全原因。通常我会同意409是一个很好的状态代码。那已经存在了。但是在用户帐户/身份验证/授权等环境中，我倾向于不公开数据库中的现有用户帐户。

当然，在这个地方还有其他处理安全性的机制。如果您不介意公开少量帐户，则可以向应用程序添加一个行为，该行为在来自一个IP的多个409事件中返回401或403。

另一个选项（通常）是自己定义一个状态代码，使其2xx与现有的标准2xx变体不同。如果您不想处理＆＃34;已经存在＆＃34;这可能是一个选项。作为一个错误。但是，这将被视为非标准，并且在具体示例中具有与409相同的不安全特性。

Answer 5

我经常使用（WebDAV扩展名）HTTP 422 Unprocessable Entity：

请求格式正确但由于语义错误而无法遵循

Answer 6

409 => Conflict
That mean.

由于冲突，请求无法完成。例如，如果给定的文件或文件夹名称已经在父位置中存在，则POST ContentStore文件夹API无法完成。