Choosing an HTTP status code is no longer a difficult thing –racksburg

Original link: http://racksburg.com/choosing-an-http-status-code/

Open Bilingual Reading

What can be simpler than HTTP response status codes? Does the page render? Great, back 200 . Page does not exist? So it is 404 . Want to jump to another page? 302or maybe it is 301 .

I like to think of the HTTP status code as 10 yards 1 of the radio wave transmission. "Call, call, I am white Chocolate thunder, found the OK." ”

--aaron Patterson (@tenderlove) 2015-10-7

Life is beautiful ... Until someone tells you that you haven't done this REST2 yet. Then you have to sleep because you need to know if your new resource returns a status code that complies with the RFC specification 3,roy-fielding. Is it only here 200 ? Or why not 204 No Content ? There may be ... 202 Accepted Or is there 201 Created ?

Complicating matters, the official http/1.1 guide--rfc--was written in 1997. † During that year, people were also using the Netscape browser to surf the internet with 33.6 KB modems. In the present use of http/1.1 is a bit like the use of Sun Tzu's Art in modern enterprise strategy, the art of war is undoubtedly great, but I do not know how to use the specific.

Can there be an intuitive decision tree that allows you to quickly identify the few status codes you want to use and exclude irrelevant and obsolete status codes?

Of course, I can give you one now.

From where to start.

It may seem ridiculous, but I've seen too many people who can't tell, "should we use this 503 Service Unavaliable or what?" 404 Not Found "If you've been hesitant about it, then you've completely mixed up with different types of responses, and your approach is completely wrong." You should look back at the flowchart above.

There are a few things to note before you dive into the flowchart of specific specifications:

• I suggest you read RFC 7231 and httpstatuses.com
• The following content is useful for developing Web sites and designing Resstish APIs.
  • The status code is completely transparent to the specific Web server implementation
  • Of course, this completely ignores the proxy server
• I will roughly classify the response status code as three classes:

Last but not least, disclaimer: I'm not sure I'm writing exactly right, I just read some of the RFC documents used to implement useful APIs every day when Racksurg company actually works. If you think I'm wrong or if I despise your favorite status code, it could be my fault, and you can tell me exactly where it was wrong by commenting.

2xx/3xx

4XX

5XX

Conclusion: Why the status code is important

I'm not entirely sure that they really matter.

There are a lot of smart people on Facebook who created the API to return only 200 .

The basic idea against selecting a specified status code is that the existing status code is too generic for modern site/api. It does not allow the client to process return information in any meaningful way with the details of a particular application format--for example, which field of the form failed and why it failed. So why waste time on unnecessary HTTP status codes that are useless?

If you want to give a reason why it is important to use a particular status code, it is generally accepted that HTTP is a hierarchical system, and that if the response status code has a specific meaning, any proxy, cache, or HTTP framework located between the client and server can work better. I don't see this as convincing enough, especially now that everyone is starting to migrate services to HTTPS, and we prohibit any proxies or cache nodes that are not directly controlled by the server.

However, I will give you three reasons why I think the status code is still important:

2. The client has processed (or can be conveniently extended to handle) different status codes with specific behavior:

   • Compared to 302 Found , 301 Moved Permanently in Google and other search engines have better SEO effect.
   • 301 Moved PermanentlyCan be cached, 429 Too Many Requests not cached, and so on. Some client libraries can process 428 Too Many Request , pull the request back and try the request again after one day. Some clients can handle this in the same way 503 Service Unavilable .

4. Even if modern requirements are not fully met, many status codes still represent a specific response worth processing (so why not use standard status codes directly?). ）。

   • The APIs that were supposed to return and 405 Method Not Allowed return 404 made me crazy to think, "Did I hit the wrong URL or did I ask for the wrong HTTP method?" ”
   • I can tell you that if we go back 502 Bad Gateway (upstream service issues) rather than return confusing 500 Internal Server Error , then we were able to save a lot of time debugging problems.

6. Believe it or not, anyway, I believe it. A convention is being established in the widely used API to return status codes, for example 201 Created , 429 Too Many Requests as well 503 Service Unavialable . If you follow this Convention, users will be able to use your site/api more easily and solve any problems they may have.

In this case, deciding when to return what status code is the hardest, but with the right knowledge (don't say I don't know, take a closer look at the previous flowchart), picking a meaningful status code becomes much easier.

Description

Do not study RFC 2616, let's not study RFC 2068, what really works is RFC 7231.

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

• Note 1:10 yards, also known as 10 signals, is used to denote commonly used phrases in voice communication, especially law enforcement and Citizen Band (CB) radio transmission code words.

• Note 2: Descriptive State transfer: REST
• Note 3:request for Comments (RFC), is a series of files that are scheduled for numbering. The document collects information about the Internet, as well as software files for the UNIX and Internet communities. The current RFC file is sponsored by the Internet Society (ISOC). Basic Internet communication protocols are described in detail in the RfC file. The RfC file also adds many topics to the standard, such as the new development protocols for the Internet and all the records in development. As a result, almost all Internet standards are included in the RfC file.

Copyright notice this translation is for study, research and communication purposes only, welcome non-commercial reprint. Reprint please indicate the source, translator and the full link to the translation. To get the markdown source text for this article that contains the above information, please click here.

Choosing an HTTP status code is no longer a difficult thing –racksburg