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

Question

所以，作为一名开发人员，我有一个非常基本的问题，在 REST 标准 中，我们有 100 个特定原因的错误代码喜欢：

4xx 如果资源相关
5xx 如果服务器发生异常

还有很多。

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

相反，我的感觉（如果我错了请纠正我）是如果调用在服务器中成功完成（没有任何异常和错误）我们return 200 并在响应正文中 return 采用特定格式，例如：

{
   "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 和 check for 200 称为 Response code 并且我们所有的进一步功能将依赖于 status & code 响应主体本身的键。同样 如果响应代码本身不是 200 那么这实际上是与服务器有关的问题。

对于 API 的 SDK 实现，我们可以在其中执行相同的操作，始终检查 status 和 code如果Response Code为200，直接拒绝非200 Response Codes.

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

如有错误请指正？请发表意见。

提前致谢。

Answer 1

没有“REST 标准”。

但是，客户端和服务器之间有一个HTTP standard, and the original definition of REST emphasizes the notion of a uniform interface。

通过使用符合 HTTP 标准的错误代码，您可以使您的接口与其他 HTTP 接口更加统一。这使得在处理 API.

时可以重用更多现有的 HTTP 客户端代码

例如：

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

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

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

但是如果你不想要一个统一的界面，那么你根本就不需要“REST”。也许你真正需要的是 RPC interface, such as JSON-RPC or gRPC.

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

Respond 200 with error or the response code as the error code

rest

api-design

http