REST API 服务针对验证失败返回什么适当的 HTTP 状态代码？

如果“验证失败”意味着请求中有一些客户端错误，则使用 HTTP 400（错误请求）。例如，如果 URI 应该具有 ISO-8601 日期并且您发现它的格式错误或指的是 2 月 31 日，那么您将返回 HTTP 400。如果您希望实体正文中格式正确的 XML 和它无法解析。

(1/2016)：在过去五年中，WebDAV 更具体的 HTTP 422（不可处理实体）已成为 HTTP 400 的非常合理的替代方案。例如，请参阅它在 JSON API 中的使用。但请注意，HTTP 422 没有进入 HTTP 1.1，RFC-7231。

Richardson 和 Ruby 的 RESTful Web Services 包含一个非常有用的附录，说明何时使用各种 HTTP 响应代码。他们说：

400（“错误请求”）重要性：高。这是一般客户端错误状态，在没有其他 4xx 错误代码适用时使用。它通常在客户端与 PUT 或 POST 请求一起提交表示时使用，并且表示格式正确，但没有任何意义。 （第 381 页）

和：

401（“未经授权”）重要性：高。客户端尝试在未提供正确身份验证凭据的情况下对受保护资源进行操作。它可能提供了错误的凭据，或者根本没有提供。凭证可能是用户名和密码、API 密钥或身份验证令牌——无论相关服务期望什么。客户端请求 URI 并接受 401 是很常见的，这样它就知道要发送什么样的凭据以及以什么格式发送。 [...]

---

来自 RFC 4918（也记录在 http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml）：

422（Unprocessable Entity）状态码意味着服务器理解请求实体的内容类型（因此 415（Unsupported Media Type）状态码是不合适的），并且请求实体的语法是正确的（因此是 400（Bad Request） ) 状态码不合适）但无法处理包含的指令。例如，如果 XML 请求正文包含格式正确（即语法正确）但语义错误的 XML 指令，则可能会出现这种错误情况。

---

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

我建议对验证错误使用 422 UNPROCESSABLE ENTITY。

我在这里对 4xx 代码进行更详细的解释：http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/

---

这里是：

rfc2616#section-10.4.1 - 400 错误请求

由于语法错误，服务器无法理解该请求。客户端不应该在没有修改的情况下重复请求。

rfc7231#section-6.5.1 - 6.5.1。 400 错误请求

400 (Bad Request) 状态码表示服务器不能或不会处理请求，因为某些东西被认为是客户端错误（例如，格式错误的请求语法、无效的请求消息帧或欺骗性请求路由）。

指格式错误（不是格式良好）的情况！

RFC4918 - 11.2。 422 无法处理的实体

422（Unprocessable Entity）状态码意味着服务器理解请求实体的内容类型（因此 415（Unsupported Media Type）状态码是不合适的），并且请求实体的语法是正确的（因此是 400（Bad Request） ) 状态码不合适）但无法处理包含的指令。例如，如果 XML 请求正文包含格式正确（即语法正确）但语义错误的 XML 指令，则可能会出现这种错误情况。

结论

经验法则：[_]00 涵盖了最一般的情况以及指定代码未涵盖的情况。

422 最适合对象验证错误（正是我的建议：）至于语义错误 - 想想“这个用户名已经存在”验证。

400 被错误地用于对象验证

---

我会说从技术上讲它可能不是 HTTP 故障，因为（可能）有效地指定了资源，用户已经过身份验证，并且没有操作失败（但是即使规范确实包含一些保留代码，例如 402 Payment Required，这些代码不是t 严格来说也与 HTTP 相关，尽管建议在协议级别使用它以便任何设备都可以识别这种情况）。

如果情况确实如此，我会在响应中添加一个状态字段，其中包含应用程序错误，例如

4日期范围无效

---

在记录 HTTP 1.1 的 RFC 2616 中有更多关于这些错误语义的信息。

就个人而言，我可能会使用 400 Bad Request，但这只是我的个人观点，没有任何事实支持。

---

这是另一个有趣的场景来讨论。

如果它是一个类型检测 API，例如接受对某个本地存储的 parquet 文件的引用作为输入，并且在读取组成文件的块的一些元数据后，可能会意识到一个或多个块大小超过配置的阈值怎么办？因此服务器决定文件没有正确分区并拒绝启动类型检测过程。此验证可防止以下两种（或两种）情况之一：（1）处理时间长，用户体验差； (2) 服务器应用程序因 OutOfMemoryError 而爆炸

在这种情况下，什么是适当的回应？

400 (Bad Request) ? - 一般的作品。

401 (Unauthorized i.e. Unauthenticated) ? - 无关。

403 (Forbidden i.e. Unauthorized) ? - 有些人会认为在这种情况下它可能有点合适 -

422 (Unprocessable entity) ? - many older answers mention this as appropriate option for input validation failure.在我的案例中使用它让我感到困扰的是这个响应代码的定义说它是“由于语义错误”，而我不太明白语义错误在那种情况下意味着什么以及我们是否可以将这个失败视为语义错误失败。

此外，在这种情况下，作为“输入验证”一部分的“输入”的所谓简单概念可能会令人困惑，因为客户端提供的物理输入只是一个指针，是对存储在服务器中的某个实体的引用，其中实际验证是对存储在服务器中的数据（parquet 文件元数据）与客户端尝试触发的操作（类型检测）一起完成的。

413 (PayloadTooLarge)？通过不同的代码，我遇到了一个可能适合我的情况的代码，一个到目前为止没有人在这里提到过的代码，那就是 413 PayloadTooLarge，我也想知道它是否适合或不适合，因为它不是实际的有效载荷发送的请求过大，但资源的有效载荷存储在服务器中。

这让我想到这里可能更适合 5xx 响应。

507 Insufficient Storage ?如果我们说“存储”就像“内存”，如果我们还说我们在这里快速失败，声称我们没有足够的内存（或者我们可能会因为内存不足而崩溃）来处理这个工作，那么也许 507 我可以合适。但不是真的。

我的结论是，在这种情况下，由于时空相关的限制，服务器拒绝对资源调用操作，最合适的响应是 413 PayloadTooLarge

---

“验证失败”到底是什么意思？你在验证什么？您指的是语法错误（例如格式错误的 XML）吗？

如果是这种情况，我会说 400 Bad Request 可能是正确的，但不知道你在“验证”什么，就不可能说出来。

---

如果您正在验证数据而数据不是，根据已定义的规则，最好发送 422（不可处理实体），以便发件人了解他违反了商定的规则。

错误请求是针对语法错误的。像邮递员这样的一些工具会预先显示语法错误。

---