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

Question

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?

Answer 1

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.

Answer 2

The server should always return status code 200 except the server dies?

I asked the same on Software Engineering a few years ago: Do web applications use HTTP as a transport layer, or do they count as an integral part of the HTTP server?. See also Should I use HTTP status codes to describe application level events.

Specifying various status code is the part of REST API?

No, REST is transport-agnostic. It can be used on top of HTTP, but doesn't need to. Therefore it doesn't say anything about status codes.

Not using status code is common?

Depends on who you ask.

It's a matter of preference. I extremely dislike "What is the most appropriate status code for scenario X?" questions. Also, there's:

• HTTP Status Codes
• HTTP Response Status Codes – REST API Tutorial

And plenty of others. I remember there being a site offering a flowchart for determining the (most) appropriate status code.

In general, don't bother. Consistency and thorough documentation is more important than assigning the appropriate number.

Answer 3

What the team is doing may be completely appropriate for the circumstances that they are in. But labeling those patterns as REST sounds inaccurate.

I say this, because it sounds like the team hasn't given any thought to how their current messaging scheme works with generic participants in the message exchange.

For instance, caching is an important concern in the REST architectural style. In HTTP, RFC 7234 describes the caching semantics. In particular, there's a section on how cache invalidation is triggered by status codes. This in turn says that, if you aren't distinguishing between the status codes in successful and unsuccessful cases, then the generic components are going to be invalidating cached entries which shouldn't be invalidated.