补丁请求中无效输入的 REST-API HTTP 状态代码答案

【问题标题】：REST-API HTTP status code for invalid input on a Patch request补丁请求中无效输入的 REST-API HTTP 状态代码
【发布时间】：2016-11-17 16:22:57
【问题描述】：

我的应用程序上有一个更新用户密码的补丁请求。我们有一个 Ember 验证器来阻止除 1 个业务规则之外的所有无效输入，即它不应该是用作您过去 5 个密码之一的密码。

在这种情况下，我们目前返回 400 Bad Request，但是我的公司有一个用于组件可用性的仪表板，并将 400 和 500 个请求计为不可用，因为大多数应用程序都是 SOAP，它们只期望 200 和 300 个。即使我们通过 UI 适当地处理了这个 400，它仍然对我们不利。并使我们成为可用性较差的区域。

我们是否应该将此告知监控可用性的人员，并让他们针对 REST 服务更改此设置，因为随着公司创建更多 REST 应用程序，这将变得更加普遍和普遍。或者我们是否屈服并返回一个 200 也表明密码没有成功更新？

【问题讨论】：

我真的认为监控坏了。至少大多数 400 错误并不表示可用性不佳。
虽然 REST 只是一种架构风格而非协议，但它遵循使用的底层协议，即您的场景中的 HTTP。因此，它还应该尊重并重新使用这些协议的功能，即为无效输入返回一个适当的错误代码。对输入数据无效的请求返回 200 OK 可能会导致 RESTful 客户端对错误数据进行操作，从而导致更多错误输入

标签： rest ember.js http-status-codes high-availability

【解决方案1】：

我认为 400 响应不适合该服务。如果当用户的密码在最近 5 个密码中重复时服务以 400 响应，则服务器理解请求。

根据W3C：

由于格式错误，服务器无法理解请求句法。客户端不应该重复请求修改。

在您的情况下，请求已被理解。它返回 400 表示 应用程序 问题（关于密码重用）。我相信 200 响应更适合指示应用程序问题的有效负载。

编辑： 也有人可能会争辩说422 response 是合适的：

422 (Unprocessable Entity) 状态码表示服务器理解请求实体的内容类型（因此 415（不支持的媒体类型）状态码不合适），并且请求实体的语法是正确的（因此是 400 (Bad Request) 状态码不合适）但无法处理包含的指示。例如，如果 XML 请求正文包含格式正确（即语法正确），但是语义错误的 XML 指令。

【讨论】：