HTTP 语义详解：为现代 Web 开发掌握 RFC 9110 标准
2022 年，IETF 发布了 RFC 9110，这是一份具有里程碑意义的文档，它取代了多个旧的 RFC（如 RFC 7231），成为 HTTP 语义 的权威规范。尽管 HTTP/2 和 HTTP/3 改变了数据的分帧和传输方式，但 语义——即方法、状态码和首部的含义——仍然是 Web 的基石。
什么是 RFC 9110 (HTTP 语义)？
RFC 9110 定义了超文本传输协议 (HTTP) 的通用架构。它与协议版本（HTTP/1.1、HTTP/2 或 HTTP/3）无关。如果您想知道 403 Forbidden 的真实含义，或者 POST 请求与 PUT 请求的行为区别，RFC 9110 就是最终的参考标准。
它为以下内容提供了一致的词汇：
- 资源 (Resources) 和统一资源标识符 (URIs)。
- 消息 (Messages)（请求与响应）。
- 方法 (Methods)（GET、POST 等）。
- 状态码 (Status Codes)（200、404 等）。
- 首部字段 (Header Fields)。
HTTP 语义的核心原理
1. 请求方法与幂等性 (Idempotency)
RFC 9110 中最重要的概念之一是 安全 (Safe) 方法与 幂等 (Idempotent) 方法的区别。
| 方法 | 安全 | 幂等 | 说明 |
|---|---|---|---|
| GET | 是 | 是 | 获取数据，无副作用。 |
| HEAD | 是 | 是 | 与 GET 相同，但不返回主体。 |
| PUT | 否 | 是 | 替换资源；重复请求不会产生进一步影响。 |
| DELETE | 否 | 是 | 删除资源。 |
| POST | 否 | 否 | 处理数据；多次请求可能会创建多个资源。 |
2. 状态码分类
RFC 9110 将状态码分为五类：
- 1xx (信息性): 已收到请求，正在继续处理。
- 2xx (成功): 动作已成功接收、理解并接受。
- 3xx (重定向): 需要进一步操作以完成请求。
- 4xx (客户端错误): 请求包含错误语法或无法完成。
- 5xx (服务器错误): 服务器无法完成明显的有效请求。
实际应用场景
设计 RESTful API
遵循 RFC 9110 可确保您的 API 具有良好的“发现性”，并且符合标准 HTTP 客户端和缓存的预期。例如，在成功的 POST 后使用 201 Created 而不是通用的 200 OK。
缓存优化
RFC 9110 定义了 Vary、ETag 和 Last-Modified 首部的工作方式。正确的实现可以允许 CDN 和浏览器有效地缓存数据，从而减轻服务器负担。
内容协商 (Content Negotiation)
该协议允许客户端请求特定格式（如 Accept: application/json），并由服务器响应最佳的可用的表现形式。
对比：RFC 7231 vs. RFC 9110
RFC 9110 并没有从根本上改变 HTTP 的工作方式，但它显著改进了文档：
- 合并: 它将来自多个文档的语义合并为一个。
- 清晰: 它澄清了关于部分内容（Range 请求）和身份验证的模糊点。
- 版本分离: 它明确地将“语义”（Semantic）与“传输方式”（HTTP/1.1 vs HTTP/3）分离开来。
常见问题 FAQ
Q: RFC 9110 只适用于 HTTP/1.1 吗？
A: 不是。RFC 9110 定义了适用于所有 HTTP 版本（包括 HTTP/2 和 HTTP/3）的语义。
Q: POST 和 PUT 有什么区别？
A: 根据 RFC 9110，PUT 是幂等的（替换特定 URI 处的资源），而 POST 则不是（它将数据提交给资源进行处理）。
Q: 我应该什么时候使用 403 而不是 401？
A: 当需要身份验证但验证失败或未提供时，使用 401 Unauthorized。当服务器理解请求但拒绝授权（即使凭据有效）时，使用 403 Forbidden。