QCon北京「鸿蒙专场」火热来袭!即刻报名,与创新同行~ 了解详情
写点什么

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

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

关注

评论

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

使用 HashiCorp Vault 保护 NGINX 中的 SSL 私钥

NGINX开源社区

HashiCorp SSL/TLS nginx 开源版 安全防护 保护 SSL 密钥

【年后跳槽必看篇-非广告】Kafka核心知识点-第四章

派大星

kafka Java’

如何对混合日志进行自动化解析

华为云开发者联盟

开发 华为云 华为云开发者联盟

提升系统管理:监控和可观察性在DevOps中的作用

禅道项目管理

项目管理 DevOps 系统管理

一文带你简单了解多租户模型定义以及好处

行云管家

SaaS 多租户

面试官:什么是JIT、逃逸分析、锁消除、栈上分配和标量替换?

王磊

Java 面试

数据库新手必知!轻松学习SQL外键约束的核心原理和实用技巧

测试人

软件测试

Aiseesoft iPhone Unlocker下载安装(iPhone解锁软件)

Rose

IPQ9574 and QCN9274 Industrial grade and commercial difference? Performance, transmission, etc

wifi6-yiyi

qcn9274 ipq9574

【亿级数据专题】「分布式消息引擎」 盘点本年度我们探索服务的保障容量的三大关键方案实现

码界西柚

分布式 熔断 限流 降级 2024年第二十七篇文章

四方维ECAD模型成为元器件的新标配

财见

稀疏场景高性能训练方案演变|京东广告算法架构体系最佳实践

京东零售技术

人工智能 架构 算法 GPU算力

Wireshark中的ARP协议包分析

小齐写代码

After Effects 2021中文破解直装版下载 支持M1/Intel

Rose

龙蜥社区&龙蜥理事长分获 2023 开源创新榜“优秀开源社区、优秀开源人物”奖项

OpenAnolis小助手

Linux 开源 操作系统 龙蜥社区 开源奖项

Whisk for mac下载 实时预览的轻量级网页编辑器

Rose

数字音频处理软件 Steinberg Cubase Artis 10激活版 附完整破解教程

Rose

AI的安全应答之道

统信软件

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