众所周知，每一个HTTP响应都会带有一个状态码，不过对于很多开发者来说，平时使用最多的几个状态码无外乎就是200、400、404、500等。那其他众多状态码该应用在何种场景中，什么时候应该使用哪些状态码就成为一个值得我们深入思考的问题了。即便在Facebook这样的公司中，那些聪明的开发者所构建的API也可能只返回200。为此，专门撰文分析了各个状态码的适用场景，以及我们为何要如此细致地区分不同状态码，同时还谈及了这么做的好处。
有什么是比返回一个HTTP状态码还要简单的事情呢？页面渲染了么？如果渲染，那就返回200呗。页面不存在？那就是404。需要将用户重定向到另外一个页面？那就使用302，也许301也行。
一切都是如此简单，不过当有人跟你说，你并没有以REST的方式做事情，你可能就要警醒了。新资源是否返回了RFC兼容、建议的状态码？只会是200么？也许是204 No Content、202 Accepted，抑或是201 Created？
问题在于官方HTTP/1.1指南（RFC）最初是在1997年的。那时的我们还在使用Netscape Navigator、33.6kbps的调试解调器网上冲浪呢。这就好比是在现代商业战略中使用孙子兵法一样。这些宝贵的建议并不会随着时间的流逝而发生变化。不过，我们需要真正理解他们。
如果有可视化的决策树就好了，它可以帮助你快速识别与你的情况相吻合的状态码，这样就能忽略掉那些不相关的了。请看下图。
上图看起来是显而易见的，不过我发现很多人都会陷入其中，并且提出诸如“这种情况应该使用503 Service Unavailable还是404 Not Found呢”？停。如果你在完全不同的响应类别中思考具体的状态码，那就表明你的做法是完全错误的。再来看看上面这张图。
在继续之前我提出几点：
- 你不必非得听我的，请直接查看与
- 我所面向的读者是那些创建网站或是使用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时就会更轻松，遇到问题时也更容易解决。
如果你在使用HTTP状态码时遇到了问题，还可以参考如下资源：
各位读者，相信你们中的很多人都曾经或是正在设计API，那么在这个过程中对于状态码你做过哪些思考呢？有哪些见解呢？欢迎分享出来与InfoQ的其他读者一同讨论。
本文永久更新链接地址：