在 RESTful 服务中使用 http 状态码

Question

我正在寻找一个很好的有意义的讨论，为什么人们觉得 RESTful Web 服务劫持 HTTP 响应代码并在给定 API 的上下文中为它们分配含义是个好主意。我的直觉反对它：感觉 HTTP 在这里充当传输层协议，为什么我会将我的 API 概念泄露到传输层？是的，我理解HTTP是27层图中的应用层，但分层是相对的。对于我的 API，HTTP 是一种传输方式。
现在人们说否则错误处理无法标准化。但是 REST 也没有真正标准化它。我们可以对 401 和 404 消息有点直观感到满意，但仅此而已。它的真正作用是使区分 API 错误和 API 服务器不存在/客户端未指向正确的位置等变得更加困难。

Answer 1

您认为哪些方案会带来更好的结果：

• 对 API 层重新使用 HTTP 状态代码（如 200-OK、404-Not found、500-Error 等）来表示类似的响应，这些响应大多保证在所有 RESTful API 供应商中以标准方式使用李>

或

• API 供应商返回 200-OK，并且消息正文包含自定义响应信封或正文以表示类似的内容（例如未找到和错误）

第一个场景还允许开发标准库以与那些 API 进行通信，其中第二个场景意味着每个 API 都是一个独特的案例，错误处理、缓存等事情不能以标准方式完成。