对于失败的验证或无效的重复项，我应该使用哪个状态代码？

Question

我正在使用基于 REST 的 API 构建一个应用程序，并且已经为每个请求指定状态代码。

对于验证失败的请求或尝试在数据库中添加重复项的请求，我应该发送什么状态代码？

我浏览过 http://www.w3.org/Protocols/rfc2616/ rfc2616-sec10.html 但它们似乎都不正确。

发送状态代码时有常见的做法吗？

Answer 1

对于输入验证失败： 400 Bad Request + 您的可选描述。 “RESTful Web Services”一书中建议了这一点。
对于双重提交：409 冲突

---

6 月更新2014

相关规范曾经是RFC2616，其中给出了400的使用（错误的请求）相当狭隘地作为

由于语法错误，服务器无法理解该请求

因此可能有人认为它不适合语义错误。但现在不再是了；自 2014 年 6 月起，相关标准 RFC 7231 取代了之前的 RFC2616，给出了使用400（错误请求） 更广泛地称为

服务器不能或
由于被认为是的原因，将不会处理该请求
客户端错误

Answer 2

我推荐状态代码 422，“无法处理的实体”。

11.2。 422 无法处理的实体

422（不可处理的实体）状态代码意味着服务器理解请求实体的内容类型（因此 415（不支持的媒体类型）状态代码是不合适的），并且请求实体的语法是正确的（因此 400 （错误请求）状态代码不合适）但无法处理所包含的指令。例如，如果 XML 请求主体包含格式正确（即语法正确）但语义错误的 XML 指令，则可能会出现此错误情况。

Answer 3

• 验证失败：403 Forbidden（“服务器理解该请求，但拒绝履行它”）。与流行的观点相反，RFC2616 并没有说“403 仅用于失败的身份验证”，而是“403：我知道你想要什么，但我不会那样做”。该情况可能是也可能不是由身份验证引起的。
• 尝试添加重复项：409 冲突（“由于与资源的当前状态冲突，请求无法完成。”）

您绝对应该在响应标头和/或正文中给出更详细的解释（例如，使用自定义标头 - X-Status-Reason：验证失败）。

Answer 4

200,300,400,500都非常通用。如果你想要通用的，400就可以了。

422 被越来越多的 API 使用，甚至被 Rails 开箱即用。

无论您为 API 选择哪种状态代码，都会有人不同意。但我更喜欢 422，因为我认为“400 + 文本状态”太笼统。此外，您没有利用 JSON-ready 解析器；相比之下，带有 JSON 响应的 422 非常明确，可以传达大量错误信息。

说到 JSON 响应，我倾向于标准化这种情况下的 Rails 错误响应，即：

{
    "errors" :
    { 
        "arg1" : ["error msg 1", "error msg 2", ...]
        "arg2" : ["error msg 1", "error msg 2", ...]
    }
}

这种格式非常适合表单验证，我认为就“错误报告丰富性”而言，这是需要支持的最复杂的情​​况。如果您的错误结构是这样的，它可能会满足您所有的错误报告需求。

Answer 5

数据库中的重复项应为 409 CONFLICT。

我建议使用 422 UNPROCESSABLE ENTITY 来处理验证错误。

我在此处提供了 4xx 代码的详细说明。

Answer 6

200

呃...（309, 400, 403, 409, 415, 422）...很多答案试图猜测、争论和标准化的最佳返回代码HTTP 请求成功，但 REST 调用失败。

混合使用 HTTP 状态代码和 REST 状态代码是错误。

然而，我看到许多实现混合了它们，许多开发人员可能不同意我的观点。

HTTP 返回码与 HTTP 请求 本身相关。 REST 调用是使用超文本传输​​协议请求完成的，它的工作级别低于调用的 REST 方法本身。 REST 是一种概念/方法，其输出是业务/逻辑结果，而HTTP 结果代码是传输结果。

例如，当您调用 /users/ 时返回“404 Not found”会令人困惑，因为它可能意味着：

• URI 错误 (HTTP)
• 未找到用户 (REST)

“403 Forbidden/Access Denied”可能意味着：

• 需要特殊权限。浏览器可以通过询问用户/密码来处理它。 (HTTP)
• 服务器上配置的访问权限错误。 (HTTP)
• 您需要进行身份验证 (REST)

并且列表可能会继续显示“500 服务器错误”（Apache/Nginx HTTP 引发的错误或 REST 中的业务约束错误）或其他 HTTP 错误等...

从代码中，很难理解失败原因是什么，是 HTTP（传输）失败还是 REST（逻辑）失败

如果 HTTP 请求在物理上成功执行，则无论记录如何，它都应该始终返回 200 代码。 (s) 是否找到。因为 找到 URI 资源并由 HTTP 服务器处理。是的，它可能会返回一个空集，其中包含 200 作为 HTTP。结果，对吗？

您可以返回 200 HTTP 代码，并带有一些选项：

• 如果出现问题，JSON 结果中的“错误”对象
• 如果没有找到记录，则为空 JSON 数组/对象
• 布尔结果/成功标志与之前的选项相结合此外

，一些互联网提供商可能会拦截您的请求并返回 404 HTTP 代码，这并不意味着找不到您的数据，而是在传输级别出现问题。

来自 Wiki：

2004 年 7 月，英国电信提供商 BT 集团部署了 Cleanfeed
内容拦截系统，它会向任何请求返回 404 错误
被 Internet Watch 识别为潜在非法的内容
基础。其他 ISP 在同一情况下返回 HTTP 403“禁止”错误
情况。使用假 404 错误作为手段的做法
泰国和突尼斯也有隐瞒审查制度的报道。在
突尼斯在 2011 年革命之前审查制度很严厉，
人们开始意识到假 404 错误的本质并创建了
一个名为“Ammar 404”的虚构人物，代表“看不见的东西”
审查员”。

为什么不简单地回答这样的问题？

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

Google 总是在其地理编码 API 中返回 200 作为状态代码，即使请求在逻辑上失败：https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes

对于成功的 HTTP 请求，Facebook 始终返回 200，即使 REST 请求失败： https://developers.facebook.com/docs/graph -api/using-graph-api/error-handling

很简单，HTTP 状态代码是针对 HTTP 请求的，定义您的状态代码。

Answer 7

Ember-Data 的 ActiveRecord 适配器期望从服务器返回 422 UNPROCESSABLE ENTITY。因此，如果您的客户端是用 Ember.js 编写的，则应该使用 422。只有这样 DS.Errors 才会填充返回的错误。 您当然可以将 422 更改为适配器中的任何其他代码 。

Answer 8

状态代码 304 未修改 也会对重复请求做出可接受的响应。这类似于使用实体标签处理 If-None-Match 标头。

在我看来，@Piskvor 的答案对于我所认为的原始问题的意图来说是更明显的选择，但我有一个也相关的替代方案。

如果您希望将重复请求视为警告或通知而不是错误，则响应状态代码为 304 Not Modified，并且 Content-Location 标头标识现有资源同样有效。当目的只是为了确保资源存在时，重复请求不会是错误，而是确认。请求并没有错误，只是多余，客户端可以参考现有的资源。

换句话说，请求是好的，但是由于资源已经存在，所以服务器不需要进行任何进一步的处理。

Answer 9

我得出的结论是尝试遵循这个规则：如果它表明客户端开发人员错误，请使用 400 （错误请求）。否则，假设根本没有客户端验证，如果愚蠢用户输入无效数据，则使用422（不可处理实体）。如果有疑问，请优先选择 422，或者也许使用更容易实现的。

这有助于开发人员知道谁真正犯了错误，无论是他自己还是用户。

我所说的“愚蠢的用户”是指非技术用户。攻击者在这里不重要：如果您担心的话，您一开始就不会使用 HTTP 状态代码。 :)

例如，如果您要根据 JSON 架构验证 JSON 请求正文，则 400 是正确的选择（例如缺少键、关键字不匹配）。但是，如果您希望用户输入有效的电子邮件，那么您应该使用 422 （让我再说一遍，假设没有客户端验证）。

这也有助于更好的分支逻辑。例如，在 REST API 的上下文中，假设您有一个调查响应端点，可能具有 POST 和 PATCH 方法。在这种情况下，如果客户端发送无效的 POST 请求，当状态代码为 422 时，您可能需要将新资源的 URI 发送回 Location 标头中，但不适用于 400。

现实世界的例子肯定更复杂，但恕我直言，这应该很有效。

Answer 10

我想每个人对此都会有不同的看法，因为我们都在不同的上下文中提到过状态代码。但重要的是最广泛接受和了解的东西。 400 被认为是验证错误响应并被接受，而 409 顾名思义是冲突。如果我们说 400 不适合验证错误，因为服务器已经理解了请求，那么想象一下有人问你一个你确实从文字中理解的问题，但你可以回答并说“哦，这是一个无效的问题”或“这确实如此”没有意义”，所以仅仅因为你理解了这些词并不意味着它有意义。否则我们可以整天谈论这个