1.4 HTTP 协议基础：契约的载体与语法

1.4 HTTP 协议基础：契约的载体与语法

本节摘要：HTTP 是承载 REST 契约的默认语法——方法表达意图，URI 定位资源，状态码回执结果，头部补足自描述信息，请求体与响应体承载资源的表示。本节用一张请求解剖图和一次完整握手，把 HTTP 这套"契约的语言"逐段拆干净，为第 2 章的方法与状态码条款及第 4 章的序列化做语法铺垫。

学习目标

阅读完本节，你应当能够：

1. 拆解一份 HTTP 请求：请求行、头部、空行、请求体各写什么。
2. 拆解一份 HTTP 响应：状态行（状态码与原因短语）、头部、主体。
3. 举例五个核心头部的作用，包括内容协商与缓存相关的头部。
4. 用一次 GET 加一次 PUT 的组合，复述"请求怎么表示客户端意图"。

一、为什么要从 HTTP 的语法表开始

第 1.3 节已经定了方向：多数 REST 接口选 HTTP 当载体。接下来就要会读这门语言的词法——不然第 2 章讲"方法语义是你的动词、状态码是你的回执"时，你会卡在没有语感的地基上。

HTTP 其实不怕学，它本质是一份"人类能读的文本信封"：请求是一封问询，响应是回信，两者都分头（头部）和身（主体）。把信封的四个格子认全，就掌握了八成语法。

二、一份 HTTP 请求的解剖

先把一份典型 GET 请求拆开看：

GET /book/42 HTTP/1.1
Host: api.example.com
Accept: application/json
X-Request-Id: 88f0-9a12
​

三段构成：

• 请求行：GET /book/42 HTTP/1.1。依次是方法（意图）、URI（指向哪份资源）、协议版本。
• 头部：Host 告诉服务器访问哪台虚拟主机；Accept 声明"我期望的表示格式"；X-Request-Id 是自定义的追踪号，方便全链路排查。
• 空行之后可以有请求体：上面的 GET 没有体；入参如果放体里，通常是创建或更新类请求。

再看一份带请求体请求的解剖：

POST /book HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 74

{"title":"设计中的设计","author":"小七","pages":240}
​

这里 Content-Type 声明主体的媒体类型，Content-Length 声明字节长度。服务器读到这封请求，就知道"要在 /book 下新增一份 JSON 表示的资源"。

三、一份 HTTP 响应的解剖

服务器回信也分境界。拿一次成功创建回执来看：

HTTP/1.1 201 Created
Location: http://api.example.com/book/42
Content-Type: application/json
Cache-Control: max-age=3600

{"id":42,"title":"设计中的设计"}
​

• 状态行：HTTP/1.1 201 Created。201 是状态码，Created 是原因短语，两者合起来回执"创建成功了"。
• 头部：Location 给出新资源的 URI，客户端拿它去 follow；Cache-Control 声明缓存策略；Content-Type 说清主体格式。
• 主体：资源的表示。

四、一张图看清楚信封四格

把请求与响应归纳成一张解剖透视图，四格里各自写什么都一目了然：

图：HTTP 请求与响应解剖示意图

五、方法、状态码、头部是三条主线

不必背整张状态码表，先建立三类印象，细节在第 2、3 章补：

• 方法表达意图：GET 读、POST 建、PUT 整体替换、PATCH 局部改、DELETE 删。安全与幂等的语义，第 2 章大篇幅展开。
• 状态码回执结果：2xx 成功（200、201、204）、3xx 重定向、4xx 客户端错（400、401、403、404）、5xx 服务器错（500、503）。
• 头部补全自描述：Content-Type 说格式，Accept 议格式，Authorization 递凭证，Cache-Control 管缓存。

💡 关键直觉：读者只要能"读懂信封四格 + 认得方法状态码头部三类记号"，就能在故障时拆开任何一次通信，判断问题出在客户端还是服务器端。这是后续排查一切接口问题的基本功。

六、一次完整含义的复述

把前面凑合成完整脚本：客户端向 /book 发 POST（信封：方法 POST、URI /book、头 Content-Type json、体 JSON），服务器验完数据回 201 Created，Location 指向 /book/42。客户端再按 Location 发一次 GET /book/42，服务器回 200 OK 带上书资源的 JSON。两次握手之间没有"会话记忆"，全靠请求自描述——正是无状态与自描述消息两个约束在语法层的落点。

把这套词法用在排障上更有用。一次 504 网关超时的排查里，先看状态行确认是 5xx 跟客户端无关，再看响应头的 Retry-After 判断要不要重试，最后靠 X-Request-Id 在网关日志里把这一条请求从头到尾拎出来。能这么干，是因为信封四格各司其职：状态码告诉你"谁的锅"，头部告诉你"怎么补救"，追踪号告诉你"往哪查"。这就是语法表真正的价值——不是考试要背，而是故障时拿来拆通信。

本节要点回顾

• 要点一：请求由请求行、头部、（可选）请求体构成，响应由状态行、头部、主体构成。
• 要点二：方法表达意图，状态码回执结果，头部补全自描述。
• 要点三：Content-Type 与 Accept 完成表示格式的协商。
• 要点四：Location 引导客户端 follow 新资源，是超媒体的语法入口。
• 要点五：读懂信封四格是排查一切接口问题的基本功。
• 要点六：HTTP 语法是第 2 章方法、状态码、URI 条款与第 4 章序列化条款的共同地基。

语法表已备齐。下一章我们就进到车间二，开始拼装契约的四大构件——先从那根最粗的主体柱"资源建模"动工。