我正在实现 Web 服务的用户注册。
当有人想要注册帐户时，我的WS会向他/她的邮件发送激活链接。在单击此链接之前，不会激活用户帐户(但信息将保留在数据库中，因此资源存在(。
所以我的问题是，如果您尝试多次注册同一封邮件，您将获得 409 冲突代码。但是有两种情况：
- 待确认的用户帐户
- 用户已注册并激活
我想知道什么是正确的方法。我应该"发明"一个HTTP状态4XX来区分它们，还是发送带有JSON信息的409？其他解决方案？
感谢！
编辑：
我发现了这个响应 -> https://stackoverflow.com/a/3290369/1171280 Piskvor 建议使用 409 状态和请求标头来解释它失败的原因和/或正文。哪一个？页眉？身体？双？
你觉得怎么样？
编辑2：
HTTP状态+带有详细错误的正文(甚至带有机器可解析的代码(是可以的，Twitter这样做(https://dev.twitter.com/docs/error-codes-responses(并尊重:)。但我仍然怀疑 403 与 409...：S
待处理帐户是一种特殊类型的用户帐户，因此我认为在您的问题的上下文中，这两个帐户(已注册和待处理(是相同的。在这两种情况下，都应返回 409。对于 REST API，这两种情况相同，因为系统中已存在该资源。
关于您更新的问题，我建议使用正文(JSON(发送错误，而不是使用自定义HTTP标头来解释调用失败的原因。原因是在正文中可以有多个错误消息(每个错误消息作为单独的 JSON 对象/数组元素(，而在标头中，您只能有一个(尽管您可以根据某些字符进行拆分(。其他原因是，您可以使用一种通用的错误处理方法，该方法在 JSON 中查找"错误"对象，而不是为每个故障场景查找不同的自定义标头。
HTTP代码：
403 - 服务器理解请求，但拒绝满足它。授权将无济于事，请求不应该重复。
409 - 由于与资源的当前状态冲突，无法完成请求。此代码仅在预期用户可能能够解决的情况冲突并重新提交请求。
我认为应该是 409，因为可以通过使用不同的电子邮件地址重新发出请求来解决冲突。
HTTP状态代码并不意味着"发明"。
409 CONFLICT对我来说听起来还可以。在正文中包含详细信息也可以，如果您的客户需要知道。
不要使用 409。使用 403。
[409] 仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许。
它适用于本应正常但存在可以解决的问题的请求。如果您编辑文档并PUT修订后的文本，但其他人在您之前做了同样的事情，您应该有机会查看其他人的工作，这样您就不会意外撤消他们的所有工作。你会得到一个409，这意味着，如果你想修改它，你应该发送你的修订，并表明你已经看到了其他人的最新修订 - 即你知道你在做什么。
没有办法"纠正"多余的注册尝试。避免冲突的唯一方法是使用不同的用户名注册，但这是非常不正确的。
我正在想象一个POST请求，它采用用户名和电子邮件地址，并创建一个专用于该新用户的新资源(现在应该用于验证(，并在电子邮件中发送该资源的 URL。因此，您正在处理POST请求处理程序拒绝创建新资源的问题，其原因特定于应用程序的业务模型(而不是与 HTTP 相关的原因，如语法错误(。
没有比 403 更具体的状态代码了。在这种情况下，你应该使用HTTP的词汇表来传达"这是不允许的"——使用HTTP顶部的层来传达原因，比如礼貌的HTML页面或JSON对象，供客户端理解并呈现为礼貌的HTML页面。
409 应该没问题;有关详细信息，https://datatracker.ietf.org/doc/html/draft-nottingham-http-problem-04 可能会感兴趣。