rest - 响应 200 错误或响应代码作为错误代码

Question

因此，作为一名开发人员，我有一个非常基本的问题，在 REST 标准 中，我们有 100 多个特定原因的错误代码，例如:

1. 4xx 如果资源相关
2. 5xx 如果服务器出现异常

还有更多。

现在谈到实现时，有些情况下我们直接返回 404 作为响应状态代码 在响应正文中包含错误消息.对于这种方法，有一点我觉得有点令人困惑，如果 URI 本身从未被创建，这意味着假设/a/b 没有实现并且正在他们响应 404 的任何服务器，并且作为客户端他们检查代码并说如果他们正在使用此 API 搜索用户，则找不到用户。

相反，我的感觉(如果我错了请纠正我)是如果调用在服务器中成功完成(没有任何异常和错误)我们返回 200 并在响应正文中返回一种特定的格式，例如:

{
   "status" : boolean, // if the overall call succeeded
   "message" : string, // message from server
   "code" : integer, // code, http code or business level code 
   "data" : object,//actual data
   "type" : string, // type of the data like object, basic, array,  (basically a value from enum)
}

任何调用的响应码总是200，具体代码在响应格式的code键中可用。

现在从客户端的角度来看这些 REST 调用的使用，在客户端中，无论是浏览器、IOS、Android 还是桌面应用，我们调用 API 并检查 200 作为响应代码，我们所有的进一步功能将取决于响应主体本身的status 和code 键。同样如果响应代码本身不是 200 那么它实际上是与服务器有关的问题。

对于 API 的 SDK 实现，我们可以在它们内部做同样的事情，如果响应代码为 200，则始终检查状态和代码，并拒绝直接非200响应码。

我觉得使用这种方法，客户端和 SDK 端的实现会更加通用和直接。

如果我说错了请指正？请发表一些看法。

提前致谢。

Answer 1

没有“REST 标准”。

但是，有一个 HTTP standard , 和 original definition of REST强调 uniform interface 的概念在客户端和服务器之间。

通过使用符合 HTTP 标准的错误代码，您可以使您的接口(interface)与其他 HTTP 接口(interface)更加统一。这使得在处理您的 API 时重用更多现有 HTTP 客户端代码成为可能。

例如:

• 大多数客户端在收到意外状态代码时会自动停止处理响应。如果您总是发送 200(OK)，他们需要额外的逻辑以免混淆。
• 有些客户端可以在收到 503 (Service Unavailable) 时自动重试请求.
• 有客户可以cache HTTP 响应取决于其状态代码。

请注意，没有什么能阻止您在响应负载中发送自定义错误代码，就像在您的示例中一样，除了标准的 HTTP 状态代码。 (事实上​​ ，这是一种常见的做法，它本身已在 RFC 7807 中标准化。)

现在，您很可能不需要统一的界面。正如评论所指出的，您可能正在构建一些内部的东西。

但是如果你不想要一个统一的界面，那么你根本就不需要“REST”。也许你真正需要的是 RPC接口(interface)，例如JSON-RPC或 gRPC .