对于一般不成功的请求（不是错误），适当的 HTTP 状态代码响应是什么？

Question

我正在创建一个 RESTful API，它将处理许多用户交互，包括使用存储的信用卡下订单。

如果订单成功，我将返回 200 OK；如果订单请求格式错误或无效，我将返回 400 Bad Request。但如果订单实际处理过程中出现问题，我该怎么退货呢？

1. 客户端向服务器发布用户资源的订单。如果用户不存在，则返回404 Not Found。
2. 订单格式和信息经过验证。如果无效，则返回 400 Bad Request。
3. 订单已处理。如果订单成功，订单会返回201 Created。如果遇到意外错误，则会返回 500 服务器错误。

最后一步是问题 - 如果订单因任何其他原因未完成，我应该返回什么？可能的情况可能包括：

• 产品已售完
• 用户最大订单限额达到
• 信用卡​​交易失败（资金不足等）

这似乎不适合 400 或 500。如果有的话，我可以将其视为如果没有更好的代码，则返回 400 - 根据业务规则，该请求无效。它只是看起来不准确。

编辑：还发现 同一主题的现有讨论。所有答案似乎都指向使用状态代码来处理此类违规，并在使用 400、409 或 422 扩展之间进行了一些讨论。

Answer 1

您应该使用 4xx 作为业务规则。如果订单未被接受，请勿返回 2xx。 HTTP 是一个应用程序协议，永远不要忘记这一点。如果您返回 2xx，则无论您在正文中发送的任何信息如何，客户都可以假设订单已被接受。

---

From [RESTful Web Services Cookbook][1]:

某些网络服务常犯的一个错误是返回状态
反映成功的代码（状态代码从 200 到 206 以及从 300
到 307），但包括描述错误情况的消息正文。
这样做可以防止 HTTP 感知软件检测到错误。为了
例如，缓存会将其存储为成功响应并将其提供给
后续客户，即使客户可能能够取得成功
请求。

Answer 2

如果客户端可以修改请求来解决错误，则应使用 4xx 来表示客户端错误。使用 5xx 表示客户端无法真正解决的服务器错误。

产品售完将是服务器错误。客户端无法以某种方式修改请求来解决错误。您可以切换到其他产品，但这不是一个新的请求吗？

达到用户最大订单限制也是服务器错误。客户端无法解决该错误。

信用卡交易失败将是客户端错误。客户可以使用不同的付款方式或信用卡号重新提交请求来解决该错误。

Answer 3

错误类型：

4×× Client Error

错误代码：

422 Unprocessable Entity

服务器了解请求实体的内容类型（因此 415 不支持的媒体类型状态代码是不合适的），并且请求实体的语法是正确的（因此 400 错误请求状态代码是不合适的），但是无法处理所包含的指令。

例如，如果 XML 请求正文包含格式正确（即语法正确）但语义错误的 XML 指令，则可能会发生此错误情况。

https://httpstatuses.com/422

Answer 4

我知道这个问题很老了，但我今天又提出了同样的问题。如果我的用户用完积分，我的 REST API 应返回什么状态代码？

我倾向于402 Payment required：

根据Wikipedia :

保留供将来使用。最初的目的是该代码可能被用作某种形式的数字现金或小额支付方案的一部分，但这种情况并未发生，并且该代码通常不被使用。如果特定开发者超出了每日请求限制，Google Developers API 就会使用此状态。

事实上他们确实这样做：

PAYMENT_REQUIRED (402)

• 已达到开发者设定的每日预算限额。
• 请求的操作需要的资源超过配额允许的资源。需要付款才能完成操作。
• 所请求的操作需要经过身份验证的用户进行某种付款。

Answer 5

424 失败依赖怎么样？规范将其描述为：

无法对资源执行该方法，因为请求的操作依赖于另一个操作，并且该操作失败。

但还有这个定义：

状态代码 424 在 WebDAV 标准中定义，适用于客户端需要更改其正在执行的操作的情况 - 服务器在此没有遇到任何问题。

您可以告诉客户（或假装）您有应该创建订单并扣除余额的内部操作，并且其中一项操作失败了，尽管原因完全正当，这就是请求失败的原因。

据我所知，“行动”是一个相当宽泛的术语，可以在多种情况下使用，包括库存不足、信用不足或仓库派对之夜。

---

另一个选项可能是422 Unprocessable Entity：

服务器了解请求实体的内容类型（因此 415 不支持的媒体类型状态代码是不合适的），并且请求实体的语法是正确的（因此 400 错误请求状态代码是不合适的），但无法处理包含的指令。

例如，如果 XML 请求正文包含格式正确（即语法正确）但语义错误的 XML 指令，则可能会出现此错误情况。

尝试请求缺货的商品，或者当您信用不足时，可能会被视为语义级别的错误。

MozDev 说这表明客户端出现错误，具体来说：客户端不应在未经修改的情况下重复此请求。

Loopback 4 当输入验证失败时使用 422。

---

可以说，库存不足或仓库派对之夜可以被视为临时状态，因此可以稍后重试该请求。这种情况可以通过 503 Service Unavailable 来指示

由于临时过载或计划维护，服务器当前无法处理请求，延迟一段时间后可能会得到缓解。

服务器可以发送 Retry-After 标头字段来建议客户端在重试请求之前等待适当的时间。

Answer 6

我不认为400可以用于所有的业务场景。它可用于基本数据输入验证。除此之外，我们可能很难将其他业务逻辑融入到这个错误代码中。由此处理的错误主要是开发人员在客户端编码期间可能遇到的设计时错误。

假设所有参数都是正确的，并且假设我们将用户帐号传递到请求中。

所以请求现在不再是一个错误的请求，服务器能够接受该请求。但现在它拒绝根据可用的新信息满足请求，即帐户没有足够的余额。

我建议在这些情况下我们应该使用 403 和适当的错误消息。

其他可能的错误代码可能是 409 冲突。但这是在资源处于一致状态的场景中使用的。

Answer 7

我选择 406 不可接受。

这是 4xx 列表：

const HTTP_BAD_REQUEST = 400;
const HTTP_UNAUTHORIZED = 401;
const HTTP_PAYMENT_REQUIRED = 402;
const HTTP_FORBIDDEN = 403;
const HTTP_NOT_FOUND = 404;
const HTTP_METHOD_NOT_ALLOWED = 405;
const HTTP_NOT_ACCEPTABLE = 406;
const HTTP_PROXY_AUTHENTICATION_REQUIRED = 407;
const HTTP_REQUEST_TIMEOUT = 408;
const HTTP_CONFLICT = 409;
const HTTP_GONE = 410;
const HTTP_LENGTH_REQUIRED = 411;
const HTTP_PRECONDITION_FAILED = 412;
const HTTP_REQUEST_ENTITY_TOO_LARGE = 413;
const HTTP_REQUEST_URI_TOO_LONG = 414;
const HTTP_UNSUPPORTED_MEDIA_TYPE = 415;
const HTTP_REQUESTED_RANGE_NOT_SATISFIABLE = 416;
const HTTP_EXPECTATION_FAILED = 417;
const HTTP_I_AM_A_TEAPOT = 418;                                               // RFC2324
const HTTP_MISDIRECTED_REQUEST = 421;                                         // RFC7540
const HTTP_UNPROCESSABLE_ENTITY = 422;                                        // RFC4918
const HTTP_LOCKED = 423;                                                      // RFC4918
const HTTP_FAILED_DEPENDENCY = 424;                                           // RFC4918
const HTTP_RESERVED_FOR_WEBDAV_ADVANCED_COLLECTIONS_EXPIRED_PROPOSAL = 425;   // RFC2817
const HTTP_UPGRADE_REQUIRED = 426;                                            // RFC2817
const HTTP_PRECONDITION_REQUIRED = 428;                                       // RFC6585
const HTTP_TOO_MANY_REQUESTS = 429;                                           // RFC6585