众所周知，每一个HTTP响应都会带有一个HTTP状态码（HTTP Status Code），是用来表示HTTP服务器响应状态的代码。它由RFC 2616规范定义的，并得到RFC 2518、RFC 2817、RFC 2295、RFC 2774、RFC 4918等规范扩展。作为web开发者，平时经常200、301、302、404、500、503等。最近正在开发一些对外的接口（公司内部各系统间互相调用的接口，也算是内部Open API吧），接口调用失败时需要返回一些状态码，考虑借用HTTP状态码的含义，可以让调用方通过状态码就能够大体知道出了什么问题，不用彼此重新约定不熟悉的编码规则，方便沟通及错误定位。自认为想法不错，但是在实际编写中遇到了问题，这个多的状态码该怎么用？就用这个机会好好学习下什么场景用什么状态码，也通过本文记录一下HTTP状态码的内容。在本文中借Michael Kropat的《Choosing an HTTP Status Code — Stop Making It Hard》中提供的状态码使用决策树，区分常用状态码的使用场景。
注：本文只是提供HTTP状态码的状态信息及含义，以及Michael Kropat总结的常用状态码决策树。
HTTP定义遵循一条规则：所有状态码的第一个数字代表了响应的状态。1表示消息；2表示成功；3表示重定向；4表示请求错误；5、6表示服务器错误。如下图：
1XX：消息
这一类型的状态码，代表请求已被接受，需要继续处理。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束。由于 HTTP/1.0 协议中没有定义任何1xx状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送1xx响应。而且Michael Kropat的文章中也没有对应该类状态码的决策树，因此此类状态码暂且作为了解。
2XX：成功，3XX：重定向
这两种请求都是服务器接收并理解请求内容，而且对请求内容做出了相应处理。决策树如下：
2XX详解
该类状态码代表请求已成功被服务器接收、理解、并处理。
3XX详解
该类状态码代表需要客户端采取进一步的操作才能完成请求。通常，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的Location域中指明。当且仅当后续的请求所使用的方法是GET或者HEAD时，用户浏览器才可以在没有用户介入的情况下自动提交所需要的后续请求。客户端应当自动监测无限循环重定向（例如：A->A，或者A->B->C->A），因为这会导致服务器和客户端大量不必要的资源消耗。按照 HTTP/1.0 版规范的建议，浏览器不应自动访问超过5次的重定向。
4XX：请求错误
这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。除非响应的是一个HEAD请求，否则服务器就应该返回一个解释当前错误状况的实体，以及这是临时的还是永久性的状况。这些状态码适用于任何请求方法。浏览器应当向用户显示任何包含在此类错误响应中的实体内容。
如果错误发生时客户端正在传送数据，那么使用TCP的服务器实现应当仔细确保在关闭客户端与服务器之间的连接之前，客户端已经收到了包含错误信息的数据包。如果客户端在收到错误信息后继续向服务器发送数据，服务器的TCP栈将向客户端发送一个重置数据包，以清除该客户端所有还未识别的输入缓冲，以免这些数据被服务器上的应用程序读取并干扰后者。
5XX、6XX：服务器错误
这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。除非这是一个HEAD请求，否则服务器应当包含一个解释当前错误状态以及这个状况是临时的还是永久的解释信息实体。浏览器应当向用户展示任何在当前响应中被包含的实体。
这些状态码适用于任何响应方法。