如何选择正确的HTTP状态码

如何选择正确的HTTP状态码

2017-09-18 22:31

  您是否属于早期采用者或者创新人士?InfoQ正在努力为您设计更多新功能。了解更多

  很多初创的甲方公司高层认为安全就是找漏洞和修漏洞,很多乙方的工程师也没有企业安全管理的真正经验,B 站在这期间,也是摸着石头过河。因此本专题将通过分享 B 站在安全建设初期上的经验,希望能给一些安全还没起步的公司和刚跳到甲方的安全工程师一点,在安全建设上少走一些弯。

  很多初创的甲方公司高层认为安全就是找漏洞和修漏洞,很多乙方的工程师也没有企业安全管理的真正经验,B 站在这期间,也是摸着石头过河。因此本专题将通过分享 B 站在安全建设初期上的经验,希望能给一些安全还没起步的公司和刚跳到甲方的安全工程师一点,在安全建设上少走一些弯。

  本期主要内容:重磅开源KSQL:用于Apache Kafka的流数据SQL引擎 ;洞悉流程!微服务与事件协同;Kafka设计解析: 流式计算的新贵 Kafka Stream;软件架构图的艺术;从金属巨人到深度学习,人工智能(极)简史;人工智能那些事儿;Google研究人员提出在移动设备上运行神经网络的新技术

  纵观历史,运维技术经历了业务规模小的原始手工时代,ITIL管理概念下的脚本时代,和业务量增加原有情况难以维续的自动化工具时代。这与机械化、电气化和信息化的三次工业竟然有着异曲同工之妙。那么在社会纷纷猜测智能化可能引发第四次工业的今天,运维人是否应该开始思考智能化会给运维工作带来哪些影响呢?

  纵观历史,运维技术经历了业务规模小的原始手工时代,ITIL管理概念下的脚本时代,和业务量增加原有情况难以维续的自动化工具时代。这与机械化、电气化和信息化的三次工业竟然有着异曲同工之妙。那么在社会纷纷猜测智能化可能引发第四次工业的今天,运维人是否应该开始思考智能化会给运维工作带来哪些影响呢?

  众所周知,每一个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并开发过一些APIs而已。如果觉得我说的不对,或是没有使用你倾向于使用的状态码,那么请在文末的评论中指出来,大家一起讨论。

  虽说Facebook中很多聪明的开发者在构建APIs时只返回200,但我想说的是,状态码确实常重要的。现有的状态码对于现代网站/API来说有些太宽泛了。如果响应要以应用特定的格式来包含一些细节信息,比如说哪些字段验证失败了,原因是什么,这样可以让客户端以更加有意义的方式来处理响应。既然如此,那为何不多花点时间来研究一下那些“不太常用”的HTTP状态码呢?

  在谈及为何说使用具体的状态码常重要的时候,人们很爱提到的一个原因就是HTTP是个分层系统,客户端与服务器之间可能存在着代理、缓存或是其他HTTP库,如果响应码有意义,那会让这一切都工作地更好。不过,我觉得这个解释站不住脚,比如说未来大家都使用上了HTTPS,我们也禁用掉了所有代理与缓存结点,你能说这时状态码就没用了么?

  1. 客户端可以针对不同的状态码采取不同的行为(或是可以轻松扩展以应对):

  3. 不管信不信,目前很多流行的APIs建立了一些约定,比如说返回201 Created、429 Too Many Requests,或是503 Service Unavilable。如果遵循这些约定,那么用户在使用你的网站/API时就会更轻松,遇到问题时也更容易解决。

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

  我们理解您使用ad blocker的初衷,但为了InfoQ能够继续以免费方式为您服务,我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单,感谢您的理解与支持。