怎样选择正确的HTTP状态码

本文来源于我在InfoQ中文站翻译的文章。原文地址是：http://www.infoq.com/cn/news/2015/12/how-to-choose-http-status-code

众所周知。每个HTTP响应都会带有一个状态码，只是对于非常多开发人员来说，平时使用最多的几个状态码无外乎就是200、400、404、500等。那其它众多状态码该应用在何种场景中，什么时候应该使用哪些状态码就成为一个值得我们深入思考的问题了。

即便在Facebook这种公司中。那些聪明的开发人员所构建的API也可能仅仅返回200。为此。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来说有些太宽泛了。假设响应要以应用特定的格式来包括一些细节信息。比方说哪些字段验证失败了。原因是什么，这样能够让client以更加有意义的方式来处理响应。

既然如此，那为何不多花点时间来研究一下那些“不太经常使用”的HTTP状态码呢？

在谈及为何说使用详细的状态码是非常重要的时候，人们非常爱提到的一个原因就是HTTP是个分层系统，client与server之间可能存在着代理、缓存或是其它HTTP库，假设响应码有意义，那会让这一切都工作地更好。只是，我认为这个解释站不住脚，比方说未来大家都使用上了HTTPS。我们也禁用掉了全部代理与缓存结点，你能说这时状态码就没用了么？

这里。我想谈谈我认为状态码依旧非常重要的3点原因：

1. client能够针对不同的状态码採取不同的行为（或是能够轻松扩展以应对）：

301 Moved Permanently与302 Found对于Google与其它搜索引擎来说还有SEO的隐喻
301 Moved Permanently有缓存的含义。而429 Too Many Requests则没有缓存的含义，诸如此类
client库能够通过一段时间的延迟后重试请求来处理429 Too Many Requests
client库能够採取相似的方式处理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时就会更轻松，遇到问题时也更easy解决。

假设你在使用HTTP状态码时遇到了问题。还能够參考例如以下资源：

各位读者，相信你们中的非常多人都以前或是正在设计API，那么在这个过程中对于状态码你做过哪些思考呢？有哪些见解呢？欢迎分享出来与InfoQ的其它读者一同讨论。