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

Question

我正在创建一个RESTful API,它将处理大量用户交互,包括使用存储的信用卡下订单.

如果订单成功,我将返回200 OK,如果订单请求格式错误或无效,我将返回400 Bad Request.但是,如果在订单的实际处理过程中出现问题,我应该返回什么？

1. 客户端POSTS为服务器订购用户资源.如果用户不存在,则返回404 Not Found.
2. 订单格式和信息经过验证.如果无效,则返回400 Bad Request.
3. 订单已处理完毕.如果订单成功,则会为订单返回201 Created.如果遇到意外错误,则返回500 Server Error.

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

• 产品已售罄
• 达到用户最大订单限制
• 信用卡交易失败(资金不足等)

这似乎不适合400或500.如果没有更好的代码,我可以将其视为400 - 根据业务规则,请求无效.它似乎不准确.

编辑:还发现了这个相同主题的现有讨论.所有答案似乎都指向使用此类违规的状态代码,并在使用400,409或422扩展之间进行了一些讨论.

Answer 1

您应该使用400作为业务规则.如果订单未被接受,请勿返回2xx.HTTP是一种应用程序协议,永远不会忘记.如果您返回2xx,则无论您在正文中发送任何信息,客户都可以认为订单已被接受.

来自RESTful Web Services Cookbook:

一些Web服务的一个常见错误是返回反映成功的状态代码(状态代码从200到206以及从300到307),但包括描述错误情况的消息正文.这样做可以防止HTTP感知软件检测到错误.例如,缓存将其存储为成功响应,并将其提供给后续客户端,即使客户端可能能够成功发出请求.

我会留给你决定4xx和5xx,但你应该使用错误状态代码.

Answer 2

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

售罄的产品将是服务器错误.客户端无法以某种方式修改请求以绕过错误.你可以切换到另一个产品,但这不是一个新的请求？

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

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

Answer 3

错误类型:

4×× Client Error

错误代码:

422 Unprocessable Entity

服务器理解请求实体的内容类型(因此415不支持的媒体类型状态代码是不合适的),并且请求实体的语法是正确的(因此400 Bad Request状态代码是不合适的)但是无法处理包含说明.

例如,如果XML请求主体包含格式正确(即语法正确)但语义错误的XML指令,则可能发生此错误情况.

https://httpstatuses.com/422

Answer 4

我知道这个问题已经过时了,但我今天想出了同样的问题.如果我的用户没有信用,我的REST API应该返回什么状态代码？

我倾向于倾向于402 Payment Required:

根据维基百科:

保留供将来使用.最初的意图是这些代码可能被用作某种形式的数字现金或微支付方案的一部分,但这种情况并未发生,并且通常不使用此代码.如果特定开发者已超过请求的每日限制,则Google Developers API会使用此状态.

确实他们这样做:

PAYMENT_REQUIRED(402)

• 已达到开发人员设定的每日预算限额.
• 请求的操作需要比配额允许的更多资源.需要付款才能完成操作.
• 请求的操作需要来自经过身份验证的用户的某种付款.

Answer 5

怎么样424 Failed Dependency？规范将其描述为：

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

但也有这样的定义：

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

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

在我看来，“行动”是一个相当宽泛的术语，可以用于多种情况，包括库存不足、信用不足或仓库聚会之夜。

另一种选择可能是422 Unprocessable Entity：

服务器理解请求实体的内容类型（因此 415 Unsupported Media Type 状态代码是不合适的），并且请求实体的语法是正确的（因此 400 Bad Request 状态代码是不合适的）但无法处理包含的指示。

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

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

MozDev表示，这表明客户端存在错误，具体而言：客户端不应未经修改就重复此请求。

当输入验证失败时，环回 4使用422。

可以说，库存不足或仓库聚会之夜可以被视为临时状态，因此可以稍后再次重试该请求。这种情况可以表示为503 Service Unavailable

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

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