对于一般不成功的请求(不是错误)，适当的HTTP状态码响应是什么？
我正在创建一个RESTful应用程序接口，它将处理许多用户交互，包括使用存储的信用卡下单。
在订单成功的情况下，我返回200OK，如果订单请求格式错误或无效，我将返回400Bad请求。但是，如果在实际处理订单的过程中出现问题，我应该返回什么？
- 客户端将用户资源的订单发送到服务器。如果用户不存在，则404Not Found为returned.
- Order格式，并验证信息。如果无效，则处理400 Bad Request is returned.
- Order。如果订单成功，将为订单返回201 Created。如果遇到意外错误，将返回500服务器错误。
最后一步是问题-如果订单由于任何其他原因没有完成，我应该返回什么？可能的情况包括：
- 产品已售罄
- 用户最大订单限制
卡交易失败(资金不足等)
这似乎不适合400或500。如果有什么不同的话，如果没有更好的代码，我可以把它看作400 --根据业务规则，请求是无效的。它看起来并不准确。
编辑:也找到了相同主题的this existing discussion。所有的答案似乎都指向对这种类型的违规使用状态代码，并在使用400、409或422扩展之间进行了一些讨论。
回答 7
Stack Overflow用户
发布于 2012-02-22 01:27:09
对于业务规则，您应该使用400。如果订单未被接受，则不要返回2xx。HTTP是一个应用程序协议，永远不要忘记这一点。如果您返回2xx，则客户端可以假定订单已被接受，而不管您在正文中发送的任何信息。
来自RESTful Web Services Cookbook
一些web服务常犯的一个错误是返回一个反映成功的状态代码(状态代码从200到206以及从300到307)，但包括描述错误条件的消息体。这样做可以防止支持HTTP的软件检测错误。例如，缓存会将其存储为成功的响应，并将其提供给后续客户端，即使客户端可能能够发出成功的请求。
我将让您在4xx和5xx之间做出选择，但您应该使用错误状态代码。
Stack Overflow用户
发布于 2012-02-23 11:31:40
如果客户端可以修改请求以避免错误，则应使用4xx表示客户端错误。对于客户端无法真正解决的服务器错误，请使用5xx。
产品售罄将是服务器错误。客户端不能以某种方式修改请求来绕过错误。您可以切换到其他产品，但这不是一个新的要求吗？
达到用户最大订单限制也是一个服务器错误。客户端不能做任何事情来解决这个错误。
信用卡交易失败将是一个客户端错误。客户可以使用不同的付款方式或信用卡号码重新提交请求，以解决此错误。
Stack Overflow用户
发布于 2016-07-08 17:13:45
错误类型：
4×× Client Error错误码：
422 Unprocessable Entity服务器了解请求实体的内容类型(因此，415不支持的媒体类型状态代码是不适当的)，并且请求实体的语法是正确的(因此，400错误的请求状态代码是不适当的)，但是无法处理所包含的指令。
例如，如果XML请求正文包含格式正确(即语法正确)但语义错误的XML指令，则可能出现此错误情况。
https://stackoverflow.com/questions/9381520
复制相似问题
腾讯云开发者
