问题
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:
- 4xx if resource related
- 5xx if exception occurred in server
and many more.
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.
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)
}
The response code of any call will always be 200, with the specific code being available in code key of the response format.
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.
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.
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.
Thanks in advance.
回答1:
There is no “REST standard”.
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.
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.
For example:
- 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.
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.
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.
来源：https://stackoverflow.com/questions/45499988/respond-200-with-error-or-the-response-code-as-the-error-code