Search code examples
resthttphttpresponsehttp-status-codesconventions

HTTP response always return response code 200 even request fail, and return status code is part of REST

I recently joined a new project. In this project, all APIs in service always return status code 200. Even, if that response was should be 400 or 404, the API returns status code 200.

I asked the reason why APIs don't return other response codes, and programmers told me they don't use response code. they put information in the body.

for example, there are some missing required fields, they return response status code 200, but the body returns like this 

{"result" : "fail"}

if an unauthorized user tries to access, the status code is 200, the body returns like this 

{"result" : "unautherized"}

what I did before was very different, I always specified status code by cases and try to return suitable status code and message. I thought that this is the part of the HTTP protocol. However, they told me specifiying status code like 400, 404, 300, is part of RESTful API, and returning always 200 is the right status code because the server responded and it is alive. APIs, always have to return 200 except 500. Because when the server dies, it can't return anything.

So these are the question.

  1. The server should always return status code 200 except the server dies?
  2. Specifying various status code is the part of REST API?
  3. Not using status code is common?
Solution

  • I've joined a project that uses exactly the same strategy -- embed status message inside the response body, and leave status code to be always 200. For consistency reason, it is better to follow existed strategy during the software maintenance time. However, it is not recommended for any new project, with reasons listed below:

    1. "Specifying status code like 400, 404, 300" follows the RESTful design, but it is NOT part of REST. Actually, usage of 302 (redirect), 401 (Basic and Digest authentication), 404 (default not-found page in web server), 500 (default server error page) is popular decades ago, long before RESTful API these days (I know RESTful is proposed decades ago, but it is only popular in recent years).

    2. "Returning always 200 is the right status code because the server responded and it is alive". This is incorrect. If it is, then only 200 can be used for status code -- as long as server is "alive", it can return message. 500 is not acceptable either, as in that case, server is still "alive", it does not die... Then, as the status code should always be 200, why do we need the code?

    3. "Not using status code is common?". Actually, it is opposite. As RESTful API design scheme is more and more popular, more projects are using HTTP status code to deliver message semantics. But anyway, this is an opinion-based viewpoint.