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

This article reprinted from: Public translation Translator: Ten years Trace Link: http://www.zcfy.cc/article/904 Original: http://racksburg.com/choosing-an-http-status-code/

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 a 10-yard ¹ of radio wave transmission. "Call, call, I am white Chocolate thunder, found the OK." ”

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

<!–more–>

Life is beautiful ... Until someone tells you that you haven't done this rest² 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 ³,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 Restish 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:

The

1. Client has processed (or can be conveniently extended to handle) different status codes with specific behavior:

   • compared to 302 Found , 301 Moved Permanently The has a better SEO effect on Google and other search engines.
   • 301 Moved Permanently can be cached, while 429 Too Many requests is not cached, and so on. Some client libraries can handle the 429 Too many request , roll back the requests, and try the request again after one day. Some clients can handle 503 Service unavilable in the same way.

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

   • Those APIs that were supposed to return 405 Method not allowed but returned 404 made Me crazy to think, "Did I hit the wrong URL or the wrong HTTP m Ethod requested the service? "
   • I can tell you that if we return to 502 bad Gateway (upstream service issue) instead of returning the confusing Internal Server Error , we could have saved A lot of time to debug problems.

3. Whether you believe it or not, I believe it anyway. A convention is being established in the widely used API to return status codes such as 201 Created , 429 Too many reques TS and 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 ¹:10 code, 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 word.
• Note ²: Representational State transfer: REST
• Note ³: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.

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