API 什么时候应该抛出 4xx 状态码（错误），什么时候应该抛出 5xx？答案

【问题标题】：When should an API throw a 4xx status code (error) and when a 5xx?API 什么时候应该抛出 4xx 状态码（错误），什么时候应该抛出 5xx？
【发布时间】：2014-07-25 10:23:25
【问题描述】：

这是一个理论问题。我相信我知道答案，但我收到了相互矛盾的答案，所以我想我会在这里问。

在 W3C 网站上它说：

客户端错误 4xx 4xx 类状态码适用于客户端好像搞错了。

它也说

服务器错误 5xx 以数字“5”开头的响应状态码表示服务器知道它有错误或无法做到的执行请求。

我认为这意味着如果一个请求在语法上是正确的，但在逻辑上是错误的，例如尝试在特定属性上创建一个具有无效值的对象，那么我的 API 应该抛出一个 5xx 错误，因为服务器 DID理解请求，但发现它无效。另一方面，我被告知它应该是 4xx 错误（特别是 400 错误请求），因为逻辑错误发生在客户端，因为它首先发送了无效值。

那么，我应该报告什么错误代码？

【问题讨论】：

我一直认为 4xx 错误可以由用户修复，而 5xx 必须通过管理来修复（例如服务器端异常）所以发送不正确的请求应该在 4xx 范围内。
@zero298 我不认为这是官方的区别......但这是一种有趣的看待它的方式，谢谢。
http-status-code-500 标签的描述是“请不要使用这个标签。对你的问题进行分类没有意义。”。请阅读标签说明，然后再将其用于您的问题。

标签： http error-handling http-status-codes http-status-code-400

【解决方案1】：

问题出在服务器端时会出现5xx错误。例如，当您使用服务器不理解的方法或协议发出请求时，当代理没有响应时等等。简而言之：当服务器无法完成请求时。

在您的示例中，4xx 错误更合适，因为请求发起者是问题的根源。更具体地说，“422 Unprocessable Entity”错误是合适的，因为正如RFC 4918 所说：

422 (Unprocessable Entity) 状态码表示服务器理解请求实体的内容类型（因此 415（不支持的媒体类型）状态码不合适），并且请求实体的语法是正确的（因此是 400 (Bad Request) 状态码不合适）但无法处理包含的说明。

出于各种原因，一些 API 设计人员试图将自己限制在一组 3 到 5 个将使用的状态代码。一般来说，这样做是为了简化 API 用户的工作，这听起来不错，但有时这种理念可能会产生更大的影响。

例如，如果我向某个 API 发送添加新评论的请求，我希望获得一些许可，例如（但不限于）：

请求是 POST，否则返回 405 状态。
如果添加了评论，我将收到 201 回复，并在正文中包含指向我的新评论的链接。

有时我会得到什么？

如果请求方式不是POST，会报400错误。
如果请求是 POST，我将返回 200 状态，有时没有指向我的新评论的链接。

听起来令人困惑？对我来说确实如此。

【讨论】：