我正在创建一个 RESTful API，它将处理许多用户交互，包括使用存储的信用卡下订单。
如果订单成功，我将返回 200 OK；如果订单请求格式错误或无效，我将返回 400 Bad Request。但如果订单实际处理过程中出现问题，我该怎么退货呢？
- 客户端向服务器发布用户资源的订单。如果用户不存在，则返回404 Not Found。
- 订单格式和信息经过验证。如果无效，则返回 400 Bad Request。
- 订单已处理。如果订单成功，订单会返回201 Created。如果遇到意外错误，则会返回 500 服务器错误。
最后一步是问题 - 如果订单因任何其他原因未完成，我应该返回什么？可能的情况包括：
- 产品已售完
- 已达到用户最大下单限额
- 信用卡交易失败（资金不足等）
这似乎不适合 400 或 500。如果没有更好的代码，我可以将其视为 400 - 根据业务规则，该请求无效。它只是看起来不准确。
编辑：还发现这个现有的讨论 https://stackoverflow.com/questions/2190945/what-http-response-code-for-rest-service-on-put-method-when-domain-rules-invalid同一主题的。所有答案似乎都指向使用状态代码来处理此类违规，并在使用 400、409 或 422 扩展之间进行了一些讨论。
您应该使用 4xx 作为业务规则。如果订单未被接受，请勿返回 2xx。 HTTP 是一个应用程序协议，永远不要忘记这一点。如果您返回 2xx，则无论您在正文中发送的任何信息如何，客户都可以假设订单已被接受。
From [RESTful Web Services Cookbook][1]:
某些 Web 服务常犯的一个常见错误是返回状态
反映成功的代码（状态代码从 200 到 206 以及从 300
到 307），但包括描述错误情况的消息正文。
这样做可以防止 HTTP 感知软件检测到错误。为了
例如，缓存会将其存储为成功响应并将其提供给
后续客户，即使客户可能能够取得成功
要求。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
