不同冲突场景的HTTP状态 [英] HTTP status for different conflict scenarios

问题描述

我正在为Web服务实现用户注册。

I'm implementing user registration for a Web Service.

当有人想注册帐户时，我的WS会向他/她的邮件发送激活链接。在单击此链接之前，不会激活用户帐户（但信息会保留在数据库中，因此资源存在）。

When somebody wants to register an account, my WS sends an activation link to his/her mail. Until this link is clicked, user account is not activated (but the info is persisted in database, so the resource exists).

所以我的问题是，如果您尝试多次注册同一邮件，你将获得409 CONFLICT代码。但是有两种情况：

So my question is, if you try to register the same mail several times, you will get a 409 CONFLICT code. But there are two scenarios right there:

1. 确认后待审的用户帐户


2. 用户已经注册并且已激活

我想知道什么是正确的方法。我应该发明HTTP状态4XX来区分它们，还是发送409带有信息的JSON？其他解决方案？

I would like to know what is the right approach. Should I "invent" an HTTP status 4XX to distinguish them, or send 409 with a JSON with info? other solutions?

Thx！

编辑：

我发现了这个回复 - > https://stackoverflow.com/a/3290369/1171280 Piskvor建议使用409状态和请求标题来解释失败和/或正文的原因。哪一个？头？身体？都？

I have found this response -> https://stackoverflow.com/a/3290369/1171280 where Piskvor suggest to use 409 status and request header to explain the reason why it failed and/or body. Which one? header? body? both?

你怎么看？

编辑2：

HTTP状态+带有详细错误的正文（机器可解析的代码均匀）没问题，Twitter就这样做了（ https://dev.twitter.com/docs/error-codes-responses ）和RESPECT :)。但我仍怀疑403 vs 409 ...：S

HTTP status + body with detailed error (with machine-parseable codes even) is OK, Twitter does that (https://dev.twitter.com/docs/error-codes-responses) and RESPECT :) . But I still doubt with 403 vs 409... :S

推荐答案

待定帐户是一种特殊类型的用户帐户，所以我认为这两个帐户（已注册和待处理）在您的问题的上下文中是相同的。在这两种情况下你应该返回409。对于REST API，两者都是相同的情况，因为该资源已存在于系统中。

Pending account is a special type of a user account, so I think both accounts (already registered and pending) are same in the context of your question. You should return 409 in both cases. For the REST API both are same cases because that resource already exists in the system.

关于更新的问题，我建议使用body（JSON）发送错误（ s）而不是使用自定义HTTP标头来解释调用失败的原因。原因是在正文中你可以有多个错误消息（每个消息都作为一个单独的JSON对象/数组元素），在标题中你只能有一个（尽管你可以根据某些字符进行拆分）。其他原因是您可以使用一种通用错误处理方法，在JSON中查找错误对象，而不是为每种失败方案查找不同的自定义标头。

Regarding your updated question, I would suggest using body (JSON) to send out error(s) instead of using a custom HTTP header to explain the reason why the call failed. Reason is that in the body can you have multiple error messages (each one as a separate JSON object/array element) where as in the header you can have only one (though you can split based on some character). Other reason is that you can have one generic error handling method which looks for an "error" object in the JSON instead of looking for different custom headers for each failure scenario.

HTTP代码：

403 - 服务器理解请求，但拒绝履行请求。授权无效，请求不应重复
。

403 - The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated.

409 - 由于冲突，请求无法完成与当前的资源状态。此代码仅允许在
情况下，预计用户可能能够解决
冲突并重新提交请求。

409 - The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request.

我认为它应该是409，因为可以通过使用不同的电子邮件地址重新发出请求来解决冲突。

I think it should be 409 because the conflict can be resolved by re-issuing the request with different email address.

这篇关于不同冲突场景的HTTP状态的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！