什么时候响应 HTTP 412 错误是合适的？答案

【问题标题】：When is it appropriate to respond with a HTTP 412 error?什么时候响应 HTTP 412 错误是合适的？
【发布时间】：2011-07-19 04:12:36
【问题描述】：

我不清楚何时应该返回 HTTP 412：Precondition Failed，Web 服务错误？我正在考虑在验证数据时使用它。例如，如果客户端 POST 的 XML 数据并且该数据缺少必需的数据元素，则响应 412 和错误描述。

这是否符合响应 HTTP 412 的精神，还是应该使用其他东西（例如另一个 http 错误代码或 Web 应用程序异常）？

【问题讨论】：

将所有 4YY 错误视为客户端错误。将 412 Precondition Failed 视为 400 Bad Request。也就是说，客户端（GUI / 脚本）向 API 发送了错误的输入。
HTTP 错误 412 在您使用行版本或时间戳来避免并发问题时使用。如果您向 Web 服务发送了一条记录并在标题中包含行版本，则 Web 服务可以将该行版本与当前行版本进行比较。如果值不匹配，您将拒绝更新请求并返回 412 错误。

【解决方案1】：

如果您查看RFC 2616，您会看到许多可用于将条件应用于请求的请求标头：

If-Match
If-Modified-Since
If-None-Match
If-Range
If-Unmodified-Since

这些标头包含“先决条件”，允许客户端告诉服务器仅在满足某些条件时才完成请求。例如，您使用PUT 请求来更新资源的状态，但您只希望在自最近的GET 之后该资源没有被其他人修改过的情况下，PUT 才会被执行。

响应状态代码412（前提条件失败）通常在这些前提条件失败时使用。

您的示例听起来像是一个无效请求（即客户端提交的数据由于缺少值而无效）。 400（错误请求）的状态代码在这里更适合 IMO。

【讨论】：

【解决方案2】：

412 保留用于请求有条件且不满足条件的情况。

对于您的用例，422 Unprocessable Entity 非常适合。

【讨论】：

【解决方案3】：

最好的办法是避免使用 412。实际上，我使用的大多数 Web 服务都会发送 400 code (Bad Request)。许多框架也内置了对 400 的支持，您的客户会喜欢更常见的错误代码。很多时候，尤其是使用 REST 接口时，会返回带有描述的简单“消息”或“错误”元素。

【讨论】：

客户端应该将任何未知的 4xx 代码视为 400。
@JoelFan 404 不会是未知代码。那个可能应该被处理，而任何未明确处理的 400-499 代码都应该被视为通用 400。
@BamaPookie - 404 是找不到资源。 412 是前提条件失败，这似乎含糊不清。这就是我们更喜欢将所有模糊响应视为 400 的原因吗？还是别的什么？