写点什么

如何选择正确的 HTTP 状态码

  • 2015-12-10
  • 本文字数:1858 字

    阅读完需:约 6 分钟

众所周知,每一个 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 来说有些太宽泛了。如果响应要以应用特定的格式来包含一些细节信息,比如说哪些字段验证失败了,原因是什么,这样可以让客户端以更加有意义的方式来处理响应。既然如此,那为何不多花点时间来研究一下那些“不太常用”的HTTP 状态码呢?

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

这里,我想谈谈我认为状态码依然很重要的3 点原因:

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

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

如果你在使用 HTTP 状态码时遇到了问题,还可以参考如下资源:

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

2015-12-10 06:565177
用户头像

发布了 88 篇内容, 共 268.8 次阅读, 收获喜欢 8 次。

关注

评论

发布
暂无评论
发现更多内容

EPBC环保生态链系统开发案例丨环保生态链EPBC源码平台

系统开发咨询1357O98O718

环保链APP系统开发案例

服务于阿里、滴滴、华为等一线互联网公司的分布式消息中间件RocketMQ核心笔记

Java架构追梦

Java 架构 面试 RocketMQ 消息中间件

刚拿到蚂蚁金服架构师offer!大佬教你如何成为offer收割机

比伯

Java 编程 架构 面试 计算机

四币连发平台系统开发详解丨四币连发源码(案例)

系统开发咨询1357O98O718

四币连发系统开发案例详解

区块链信息共享应用落地搭建解决方案

t13823115967

区块链+ 区块链应用 信息共享

《数据结构与抽象:Java语言描述》.pdf

田维常

数据结构

Scala中String和Int隐式转换的问题分析

木子李G

scala 大数据 编程 隐式转换

SGY奇点交易所系统软件开发|SGY奇点交易所APP开发

系统开发

请问如何短时间突击 Java 通过面试?

Java架构师迁哥

DolphinDB与Elasticserach在金融数据集上的性能对比测试

DolphinDB

数据处理 金融 时序数据库 tsdb DolphinDB

Mybatis动态映射,so easy啦

田维常

Github 2020 年度报告:你以为新冠击溃了开发者?不!他们创造了更多代码...

阿里巴巴云原生

开源 Serverless 程序员 代码

智慧警务开发,二维码定位报警系统搭建

t13823115967

智慧公安 智慧公安扫码

某美女的程序员老公半夜都还不回家,原来是偷偷在公司看Redis+JVM+Spring cloud+MySQL技术文档

Java架构之路

Java 程序员 架构 面试 编程语言

仅凭这份Java大纲笔记,我如愿拿到了阿里offer。

Java架构之路

Java 程序员 架构 面试 编程语言

区分Protobuf 3中缺失值和默认值

Gopher指北

protobuf Go 语言

恕我直言!有了这份MySQL学习文档,你收藏夹里的其他MySQL学习资料都可以扔了

Java架构之路

Java 程序员 架构 面试 编程语言

助力孩子走上学霸之路,K12学习神器现已面世!

E科讯

超详细讲解!Android面试真题解析火爆全网,搞懂这些直接来阿里入职

欢喜学安卓

android 编程 程序员 面试 移动开发

了解OAuth2.0

环信

SGY奇点交易所系统软件APP开发

系统开发

四面腾讯pcg后端开发岗,一个星期面完成功拿到20K的offer。分享面经

Java架构之路

Java 程序员 架构 面试 编程语言

用60行代码实现一个高性能的圣诞抽抽乐H5小游戏(含源码)

徐小夕

Java 大前端 H5游戏 H5

新思科技最新报告显示开源安全是首要考虑因素

InfoQ_434670063458

动态高并发时为什么推荐ReentrantLock而不是Synchronized?

moon聊技术

JVM 并发 synchronized ReentrantLock 锁升级

区块链BaaS应用平台开发

13828808769

iOS面试基础知识 (一)

iOSer

ios 面试 runtime 编程开发 iOS Developer

还有谁比阿里人更懂SpringCloud Alibaba 呢?P8大牛纯手打笔记免费分享!

Java架构之路

Java 程序员 架构 面试 编程语言

港美股交易系统开发框架构造简述篇

软件开发大鱼V15988750073

国际配售 港股交易系统开发 证券交易系统 资管系统 港股打新系统

JS&Swift

ios swift

阿里架构师经验分享!啃完999页Android面试高频宝典,面试心得体会

欢喜学安卓

android 程序员 面试 移动开发

如何选择正确的HTTP状态码_REST_张龙_InfoQ精选文章