针对不同冲突情况的HTTP状态
我正在实施Web服务的用户注册。
当有人想注册一个账户时，我的WS会发送一个激活链接给他/她的邮件。 在点击此链接之前，用户帐户不会被激活（但信息会保留在数据库中，因此资源已存在）。
所以我的问题是，如果您尝试多次注册相同的邮件，您将收到409个CONFLICT代码。 但是有两种情况：
我想知道什么是正确的方法。 我应该“发明”HTTP状态4XX来区分它们，还是发送带有信息的JSON 409？ 其他方案？
谢谢！
编辑：
我发现这个回应 - > https://stackoverflow.com/a/3290369/1171280其中Piskvor建议使用409状态和请求标题来解释失败和/或正文的原因。 哪一个？ 头？ 身体？ 都？
你怎么看？
编辑2：
具有详细错误的HTTP状态+主体（甚至可以使用机器分析代码）是OK，Twitter会执行此操作（https://dev.twitter.com/docs/error-codes-responses）和RESPECT :)。 但我仍然怀疑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语法错误等与HTTP相关的原因）。
没有什么状态代码比你想要的更适合于403.在这种情况下，所有你应该使用HTTP的词汇来沟通是'这是不允许的' - 使用HTTP之上的图层来沟通为什么，像一个礼貌的HTML页面或客户端可以理解并呈现为有礼貌的HTML页面的JSON对象。
链接地址: http://www.djcxy.com/p/45401.html