响应 200 with error 或响应代码作为错误代码 [英] Respond 200 with error or the response code as the error code

问题描述

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

So, being a developer I have a very basic question, in a REST standard we have 100's of error code for specific reason like:

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

还有更多.

现在说到实现，有些情况我们直接返回404作为响应状态码 响应正文中的错误消息强>.使用这种方法时，我认为有一点令人困惑，如果 URI 本身永远不会被制作，那意味着假设/a/b 没有被实现并且正在他们响应 404 的任何服务器，并且作为客户端，他们检查代码并说如果他们使用此 API 搜索用户，则找不到用户.

Now when it comes to the implementation there are situations when we return 404 directly as the response status code with the error message in the response body. With this approach there is a thing that I think a bit confusing, what if the URI itself is never being made, that means suppose /a/b is not implemented and being any server they respond 404, and as a client they check the code and say that the user is not found if they are searching for the user with this API.

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

Instead what I feel (correct me if I am wrong) is that if the call is successfully completed in the server (without any exceptions and errors) we return 200 and in the response body return in a specific format like:

{
   "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 键中可用.

The response code of any call will always be 200, with the specific code being available in code key of the response format.

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

Now coming to the usage of these REST call from client prospective, in the client whether it is browser, IOS, Android or Desktop app, we call the API and check for 200 as the Response code and all our further functionality will be dependent on status & code key of the response body itself. Again if the Response Code itself is not 200 then that it actually the problem with respect to the server.

谈到 API 的 SDK 实现，我们可以在它们内部执行相同的操作，方法是始终检查 状态 和 代码，如果响应代码为 200，并拒绝直接非 200 响应代码.

Coming to the SDK implementations of the API's, we can do the same inside of them, by always checking the status and code if Response Code is 200, and rejecting directly non 200 Response Codes.

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

I feel with this approach the client side as well as SDK side the implementation would be more generic and straight forward.

如果我错了请纠正我?请发表一些看法.

Please correct me if I am wrong? Please shed some views.

提前致谢.

推荐答案

没有REST 标准".

There is no "REST standard".

但是，有一个 HTTP 标准，以及 REST 的原始定义 强调了客户端和服务器之间的统一接口.

However, there is an HTTP standard, and the original definition of REST emphasizes the notion of a uniform interface between the client and the server.

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

By using error codes according to the HTTP standard, you make your interface more uniform with other HTTP interfaces. This makes it possible to reuse more of existing HTTP client code when dealing with your API.

例如:

• 大多数客户端在收到意外状态代码时会自动停止处理响应.如果你总是发送 200 (OK)，他们需要额外的逻辑以免混淆.
• 有些客户端在收到 503 (服务不可用).
• 有些客户端可以缓存 HTTP 响应，具体取决于在他们的状态代码上.

• Most clients automatically stop processing the response when they get an unexpected status code. If you always send 200 (OK), they need extra logic in order to not get confused.
• There are clients that can automatically retry requests when they receive 503 (Service Unavailable).
• There are clients that can cache HTTP responses depending on their status code.

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

Note that nothing prevents you from sending a custom error code in the response payload, like in your example, in addition to a standard HTTP status code. (In fact, this is such a common practice that it has itself been standardized in RFC 7807.)

现在，您完全有可能不需要统一的界面.正如评论指出的那样，也许您正在构建内部的东西.

Now, it’s perfectly possible that you don’t need a uniform interface. Maybe you’re building something internal, as the comments point out.

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

But if you don’t want a uniform interface, then you don’t want "REST" at all. Perhaps what you really need is an RPC interface, such as JSON-RPC or gRPC.

这篇关于响应 200 with error 或响应代码作为错误代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！