写点什么

如何选择正确的 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:565105
用户头像

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

关注

评论

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

深圳参加java培训哪个机构靠谱

小谷哥

一文详解东数西算下绿色数据中心节能减排十大技术、智算中心八大趋势

GPU算力

高效工作,文档协作必不可少

Baklib

高效工作 文档协作

【JavaWeb】Servlet系列——请求和响应过程的角色和协议、模拟Servlet本质、开发第一个带有Servlet的Webapp、关于Java EE的版本

胖虎不秃头

Web java; 9月月更

清远市等保测评公司有几家?分别在哪里?

行云管家

网络安全 等保 等保测评 等级测评 清远

2022 DEMO CHINA创新中国峰会拉开帷幕

创业邦

【JavaWeb】Servlet系列——响应HTML代码、Servlet连接数据库、IDEA开发Servlet程序、Servlet对象的生命周期、Generic

胖虎不秃头

Web java; 9月月更

从数据库发展史看数据库未来技术趋势

OceanBase 数据库

数据如何指导决策:优酷主客APP播转率的C端优化

阿里巴巴文娱技术

数据分析 数据 BI

Java注解详细

石臻臻的杂货铺

Java 阅读 9月月更

SpringBoot源码 | printBanner方法解析

六月的雨在InfoQ

源码 springboot 9月月更 springboot源码

【JavaWeb】Servlet系列——模板方法设计模式、HttpServlet源码分析、Web站点的欢迎页面、关于WEB-INF目录

胖虎不秃头

Web java; 9月月更

干货分享!JAVA诊断工具Arthas在Rainbond上实践~

北京好雨科技有限公司

Kubernetes Arthas 企业号九月金秋榜

java开发培训好还是自学好?

小谷哥

数字藏品电商平台开发:如何开发数字藏品?

开源直播系统源码

区块链 NFT 数字藏品 数字藏品系统 数字藏品软件

启科量子公布量子计算机工程化进展

启科量子开发者官方号

Maven的下载安装配置以及IDAEA中Maven的配置

守夜人st

9月月更

OpenHarmony——内核IPC机制数据结构解析

OpenHarmony开发者

OpenHarmony

软件测试 | 测试开发 | Kafka入门

测吧(北京)科技有限公司

kafka 软件测试

利用京东云Web应用防火墙实现Web入侵防护

京东科技开发者

网络安全 安全 防火墙 WEB安全 京东云

Spring源码解析(十二)Spring扩展接口SmartInstantiationAwareBeanPostProcessor解析

石臻臻的杂货铺

spring 9月月更

软件测试 | 测试开发 | 使用charles 修改服务器返回数据

测吧(北京)科技有限公司

软件测试 测试

不清楚产品帮助中心怎么设置?从这几点出发!

Baklib

产品 帮助中心

软件测试 | 测试开发 | vue双向绑定原理实现

测吧(北京)科技有限公司

Vue 测试框架

24小时的客户服务如何实现?来建立产品知识库吧!

Baklib

产品 知识库 客户服务

切流的基本逻辑

agnostic

切流

ShareSDK Android端分享与授权示例代码

MobTech袤博科技

android sdk

Java 在Word文档中添加艺术字

在下毛毛雨

Java word 添加艺术字

【DBA100人】胡中豪:国产分布式数据库DBA炼成记

OceanBase 数据库

web前端培训班口碑哪个比较好

小谷哥

软件测试 | 测试开发 | 基于php-code-coverage的增量代码覆盖率实现

测吧(北京)科技有限公司

php 测试 PHP框架

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