为此，Michael Kropat专门撰文剖析了各个状态码的适用场景，以及我们为何要如此细致地区分不同状态码，同时还谈及了这么做的好处。
有什么是比返回一个HTTP状态码还要大略的事情呢？页面渲染了么？如果渲染，那就返回200呗。页面不存在？那便是404。须要将用户重定向到其余一个页面？那就利用302，大概301也行。
统统都是如此大略，不过当有人跟你说，你并没有以REST的办法干工作，你可能就要警觉了。新资源是否返回了RFC兼容、Roy-Fielding建议的状态码？只会是200么？大概是204 No Content、202 Accepted，抑或是201 Created？
问题在于官方HTTP/1.1指南（RFC）最初是在1997年发布的。那时的我们还在利用Netscape Navigator、33.6kbps的调试解调器网上冲浪呢。这就好比是在当代商业计策中利用孙子兵法一样。这些宝贵的建议并不会随着韶光的流逝而发生变革。不过，我们须要真正理解他们。
如果有可视化的决策树就好了，它可以帮助你快速识别与你的情形相吻合的状态码，这样就能忽略掉那些不干系的了。请看下图。
上图看起来是显而易见的，不过我创造很多人都会陷入个中，并且提出诸如“这种情形该当利用503 Service Unavailable还是404 Not Found呢”？停。如果你在完备不同的相应种别中思考详细的状态码，那就表明你的做法是完备缺点的。再来看看上面这张图。
在连续之前我提出几点：
你不必非得听我的，请直接查看RFC 7231与httpstatuses.com
我所面向的读者是那些创建网站或是利用REST API的开拓者
我将相应码大致划分为3大类
末了再提一点：我实在并没有什么资格就这个主题揭橥自己的意见，我只不过阅读过一些RFC并开拓过一些APIs而已。如果以为我说的不对，或是没有利用你方向于利用的状态码，那么请在文末的评论中指出来，大家一起谈论。
2XX/3XX
4XX
5XX
为何说状态码很主要
虽说Facebook中很多聪明的开拓者在构建APIs时只返回200，但我想说的是，状态码确实是非常主要的。现有的状态码对付当代网站/API来说有些太宽泛了。如果相应要以运用特定的格式来包含一些细节信息，比如说哪些字段验证失落败了，缘故原由是什么，这样可以让客户端以更加故意义的办法来处理相应。既然如此，那为何不多花点韶光来研究一下那些“不太常用”的HTTP状态码呢？
在谈及为何说利用详细的状态码是非常主要的时候，人们很爱提到的一个缘故原由便是HTTP是个分层系统，客户端与做事器之间可能存在着代理、缓存或是其他HTTP库，如果相应码故意义，那会让这统统都事情地更好。不过，我以为这个阐明站不住脚，比如说未来大家都利用上了HTTPS，我们也禁用掉了所有代理与缓存结点，你能说这时状态码就没用了么？
这里，我想谈谈我认为状态码依然很主要的3点缘故原由：
1. 客户端可以针对不同的状态码采纳不同的行为（或是可以轻松扩展以应对）：
301 Moved Permanently与302 Found对付Google与其他搜索引擎来说还有SEO的隐喻
301 Moved Permanently有缓存的含义，而429 Too Many Requests则没有缓存的含义，诸如此类
客户端库可以通过一段韶光的延迟后重试要求来处理429 Too Many Requests
客户端库可以采纳类似的办法处理503 Service Unavilable
2. 很多状态码所表示的情形可以通过分外的相应进行处理。
返回404而非405 Method Not Allowed的APIs有时会让我抓狂，“我是输错了URL还是利用了缺点的HTTP方法呢”？
精确区分502 Bad Gateway与500 Internal Server Error会让你省下不少的调试韶光。
3. 不管信不信，目前很多盛行的APIs建立了一些约定，比如说返回201 Created、429 Too Many Requests，或是503 Service Unavilable。如果遵照这些约定，那么用户在利用你的网站/API时就会更轻松，碰着问题时也更随意马虎办理。
荐文
