热门推荐

随便看看

如何选择正确的HTTP状态码

2017-09-26 06:30

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

  《无痛的增强学习入门》系列文章旨在为大家介绍增强学习相关的入门知识,为大家后续的深入学习打下基础。其中包括增强学习的基本思想,MDP框架,几种基本的学习算法介绍,以及一些简单的实际案例。

  《无痛的增强学习入门》系列文章旨在为大家介绍增强学习相关的入门知识,为大家后续的深入学习打下基础。其中包括增强学习的基本思想,MDP框架,几种基本的学习算法介绍,以及一些简单的实际案例。

  本期主要内容:吴恩达:人工智能是新电能;Michael Jordan:目前人工智能发展到了什么地步?专访ImageNet冠军颜水成团队,如何将比赛在企业中落地?格灵深瞳:基于人工智能的新天网;机器学习与微博:TensorFlow在微博的大规模应用与实践;深度学习在美团点评推;荐平台排序中的运用;Twitter机器学习平台的设计与搭建。

  在“The Studipity Paradox”这本书里,Andre Spicer和Mats Alvesson探讨了知识密集型企业是如何雇佣了聪明人然后又鼓励他们去从事愚蠢的工作的。功能性愚蠢行为是灾难性的,不过也有些愚蠢行为是有用的。这本书提出了一些,用于抵抗愚蠢行为或减轻愚蠢行为所带来的后果,以及如何利用它们并从中获益。

  LinkedIn的飞速增长让他们的基础架构面临重重压力。为了顺利缩放并改善代码的质量、安全性,以及用户满意度,他们需要一种新的发布模型。

  众所周知,每一个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添加至白名单,感谢您的理解与支持。