HTTP状态码能用作业务语言？

banq

问题：由于 HTTP 状态代码的定义非常“技术化”，那么对于某些业务案例，是否有好的指南可供使用？有没有这方面的好书？

随机示例：如果用户请求一个事物列表，其中 50% 可以，但由于某些内部错误，50% 无法找到... 这是 200 吗？或者可以使用 206（部分），即使描述对其用途非常具体？

同样，各种客户端错误也一样，从业务角度来说，应该使用什么错误。或者 500，大多数都是纯技术性的，我们能否使用它来在服务器端传达一些业务错误，以便用于更多内部 API？

有没有好的资源讨论这个问题并展示选项？或者已经有一个公认的最佳实践？

讨论1： Http 代码与业务逻辑无关，它是通信协议。 您可以按照最适合您的系统和业务的方式使用此协议，而不是相反。 代码没有好坏之分，只有人们只要有用就会使用的惯例。 HTTP 是一种传输，其响应负载是用例\业务场景。

讨论2： 我们尝试使用 http 错误代码作为业务语言，但很快就放弃了，因为：

  1. Http 代码是技术性的，与业务混合很容易变得混乱
  2. 粒度不够细
例子：
  • GET /customers/1234 返回 404，是因为客户 1234 不存在还是 /customers 不存在（例如应该是 /clients/）？两者都需要客户端做出截然不同的反应。
  • POST /customer/purchase - 如果客户档案中的信用卡无效，应该返回什么？400？500？200？
我们最终使用 http 代码来处理纯技术性的东西：
  • 200：服务器成功处理请求。在响应主体中查看更多详细信息（例如，购买已完成或由于客户信用卡过期而未完成）。所有业务逻辑都在 200 秒内完成。
  • 400：客户端发送了无效请求（例如无效的 JSON、必填字段为空），导致问题。重试相同的请求毫无意义。
  • 500：服务器出现问题，可能是错误或某些暂时性问题。重试相同的请求可能会有效。

讨论3： 讨论2的这些问题都可以通过成熟的模型 REST API 很好地实现！

  • /customers 应该始终存在并且应该返回 200（如果它是定义的集合资源），但如果不存在则应该返回一个空的客户集合。
  • /customers/1234 完全有效，如果资源 ID 1234 不存在，则应返回 404
  • /customers/purchases - 您不太可能直接向此资源发送 POST 消息来进行付款（可能存在与购买相关的付款资源，因为付款和创建采购订单是两件不同的事情），但是在信用卡过期的情况下，如果重新提交，则会出现 http 422 错误。
如果使用无效的存储卡付款，或者资金耗尽等 - 一些创造性的许可 - 但具有定义的付款结果状态模式的 200 响应可能是合适的。

然而，做好 REST API 很棘手。

如果用HTTP 状态用好，可简单地表示业务语言，一定要简单，因为复杂了就会将两者耦合在一起，特别是需要查资料，不能一目了然，例如200表示成功，404表示不成功。