前端常用状态码

基本全部参考：http://web.jobbole.com/87212/

image.png
image.png

结语：究竟为什么状态码重要

我并不完全确定它们真的重要。

Facebook 上有许多聪明人，他们创建了 API 只返回 200。

反对挑选指定状态码的基本观点是：现有的状态码对于现代网站/API来说太通用了。它无法让客户端以任何一种有意义的方式处理包含特定应用格式的细节的返回信息 —— 例如表单的哪一个字段校验失败了以及为什么失败了。既然如此，那么为什么要在多余的没什么用的 HTTP 状态码上浪费时间？

如果要给出一个理由，来说明为什么使用特定的状态码很重要，公认的理由是 HTTP 是一个分层的系统，如果响应状态码是有特定含义的，任何代理、缓存或者位于客户端和服务器之间的 HTTP 框架能够更好地工作。我不认为这个理由足够更令人信服，尤其现在每个人都开始将服务迁移到 HTTPS，我们禁止了任何不被服务器直接控制的代理或缓存节点。

然而，我会给你三个理由为什么我认为状态码仍然很重要：

1. 客户端已经处理（或者可以方便地被扩展以便处理）具有特定行为的不同状态码：
   • 相比于 302 Found，301 Moved Permanently 在 Google 等搜索引擎上有更好的 SEO 效果。
   • 301 Moved Permanently 能够被缓存，而 429 Too Many Requests 不被缓存等等。 有的客户端库可以处理 428 Too Many Request，将请求回退并一天之后再次尝试请求。 有的客户端可以用同样的方式处理 503 Service Unavilable。
2. 即使对现代需求不能完全满足，许多状态码依然代表着值得处理的特定响应（因此为什么不直接使用标准状态码？）。
   • 那些本该返回 405 Method Not Allowed 却返回 404 的 API 让我疯狂地想，“我是否敲错了 URL 或者我请求用错了 HTTP method？”
   • 我能告诉你如果我们返回 502 Bad Gateway（上游服务问题）而不是返回让人困惑的 500 Internal Server Error，那么我们曾经能节省许多调试问题的时间。
3. 不管你信不信，反正我是信了，在广泛被使用的 API 中正在建立一个约定，以返回状态码例如 201 Created，429 Too Many Requests 以及 503 Service Unavialable。如果你遵循这个约定，用户将能更方便地使用你的网站/API并且解决任何他们可能遇到的问题。

在这里面，决定什么时候返回何种状态码是最难的，然而有了正确的知识（别再说我不知道，仔细看前面的流程图），挑选一个有意义的状态码变得简单很多。

说明

别去研究 RFC 2616，更别去研究 RFC 2068，真正有用的是 RFC 7231。

参考资料

• 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
• 注¹：10码，又称十个信号，用来表示常用的短语，在语音通信，特别是执法和公民波段（CB）无线电传输码字。
• 注²：表述性状态转移：REST
• 注³：Request For Comments（RFC），是一系列以编号排定的文件。文件收集了有关互联网相关信息，以及UNIX和互联网社区的软件文件。目前RFC文件是由Internet Society（ISOC）赞助发行。基本的互联网通信协议都有在RFC文件内详细说明。RFC文件还额外加入许多的论题在标准内，例如对于互联网新开发的协议及发展中所有的记录。因此几乎所有的互联网标准都有收录在RFC文件之中。