How to select the correct HTTP status code

How to select the correct HTTP status code

As we all know, each HTTP Response carries a status code, but for many developers, the most commonly used status codes are 200, 400, 404, and 500. In what scenarios should I use other status codes and when should I use them? This is a question worth further consideration. Even in companies like Facebook, the API built by smart developers may return only 200. To this end, Michael Kropat wrote a dedicated article to analyze the applicable scenarios of various status codes, and why we want to differentiate status codes in so detail, and also talked about the benefits of doing so.

What is easier than returning an HTTP status code? Is the page rendered? If rendering is performed, the system returns 200 bytes. Page does not exist? That is 404. Need to redirect the user to another page? Use 302, or 301.

Everything is so simple, but when someone tells you that you are not doing things in the REST way, you may be alert. Does the new resource return the RFC compatibility and Roy-Fielding suggested status codes? Is it only 200? Maybe 204 No Content, 202 Accepted, or 201 Created?

The problem is that the official HTTP/1.1 Guide (RFC) was first released in 1997. At that time, we were still using Netscape Navigator and 33.6kbps to debug the online surfing of the modem. This is like using Sun Tzu's Art of War in modern business strategies. These valuable suggestions will not change over time. However, we need to really understand them.

If you have a visual decision tree, it can help you quickly identify the status code that matches your situation, so that you can ignore irrelevant ones. See.

It seems obvious, but I find many people will fall into it, and I propose, for example, "Should we use 503 Service Unavailable or 404 Not Found in this case "? Stop. If you think about specific status codes in completely different response categories, it means that your approach is completely wrong. Let's take a look at the figure above.

Before proceeding, I propose the following points:

• You don't have to listen to me. Please check RFC 7231 and httpstatuses.com directly.
• I am targeting developers who create websites or use REST APIs.
• I divided the response code into three categories.

Finally, I would like to make another note: I am not qualified to express my views on this topic. I have read some RFC and developed some APIs. If you think that I am not correct, or do not use the status code that you prefer to use, please refer to the comment at the end of the article for discussion.

2XX/3XX

4XX

5XX

Why is the status code important?

Although many smart Facebook developers only return 200 when building an APIs, I would like to say that the status code is indeed very important. The existing status code is too broad for modern websites/APIs. If the response needs to contain detailed information in a specific format of the application, such as which fields fail to be verified and why, the client can process the response in a more meaningful way. In this case, why don't we spend some time studying the "not commonly used" HTTP status codes?

When talking about why using specific status codes is very important, one of the reasons that people love to mention is that HTTP is a hierarchical system, there may be a proxy, cache, or other HTTP library between the client and the server. If the response code is meaningful, it will make it all work better. However, I think this explanation is untenable. For example, if we use HTTPS in the future, we also disable all proxy and cache nodes. Can you say that the status code is useless at this time?

Here, I want to talk about the three reasons why I think the status code is still very important:

1. The client can take different actions for different status codes (or easily expand to cope with them ):

• 301 Moved Permanently and 302 Found have a metaphor for SEO for Google and other search engines.
• 301 Moved Permanently has the meaning of caching, while 429 Too expires Requests has no meaning of caching, and so on
• The client library can retry the request after a delay of a period of time to process 429 Too required Requests
• The client library can handle 503 Service Unavilable in a similar way

2. Many status codes can be processed through special responses.

• The response to APIs 404 instead of 405 Method Not Allowed may sometimes drive me crazy. "Do I lose the wrong URL or use the wrong HTTP Method "?
• Correctly distinguishing 502 Bad Gateway from 500 Internal Server Error will save you a lot of debugging time.

3. Believe it or not, Many popular APIs have established some conventions, such as returning 201 Created, 429 Too required Requests, or 503 Service Unavilable. If you follow these conventions, it is easier for users to use your website/API and solve problems easily.

If you encounter problems when using HTTP status codes, you can also refer to the following resources:

• HTTP status code reference
• HTTP status codes used by world-famous APIs
• HTTP status codes visualized as a subway map
• Status Codes To Cat Memes As a Service
• Status Codes To Dog Memes As a Service

Dear readers, I believe many of you have designed APIs. What do you think about status codes in this process? What insights do you have? You are welcome to share it with other InfoQ readers.

This article permanently updates the link address: