4、HTTP协议基础：请求方法、状态码与请求头响应头
说实话，HTTP协议这东西，你天天在用，但真让你说清楚，很多人就卡壳了。
我记得刚入行那会儿，接口调不通就只会盯着报错看，完全不知道问题出在哪。后来带我的老大哥说了一句话，我到现在都记得——「你连HTTP都不懂，怎么跟服务器对话？」
嗯，今天咱们就把这个「对话规则」彻底搞明白。
4.1 请求方法：你跟服务器说什么？
HTTP请求方法，说白了就是告诉服务器「你想干嘛」。常用的就四个：GET、POST、PUT、DELETE。我习惯把它们对应到数据库的增删改查上，这样好记。
| 方法 | 含义 | 类比数据库 | 幂等性 |
|---|---|---|---|
| GET | 获取资源 | SELECT | 是 |
| POST | 创建资源 | INSERT | 否 |
| PUT | 更新/替换资源 | UPDATE | 是 |
| DELETE | 删除资源 | DELETE | 是 |
核心区别：GET请求的参数在URL里，POST请求的参数在请求体里。你想想看，URL长度有限制，所以GET不能传大量数据。我在项目中遇到过有人用GET传图片base64，结果直接报414错误。
举个例子，咱们仿真脚本里要查询用户信息：
// GET请求 - 查询用户
GET /api/users/1001 HTTP/1.1
Host: localhost:8080
// POST请求 - 创建用户
POST /api/users HTTP/1.1
Host: localhost:8080
Content-Type: application/json
{
"name": "张三",
"age": 28
}我的小技巧：做接口测试时，我习惯先确认接口文档里写的请求方法对不对。有一次联调，后端把POST写成了PUT，我查了半天才发现。所以，第一步先看方法，别急着填参数。
4.2 状态码：服务器在告诉你什么？
状态码是服务器给你的「回执」。我把它分成五类，每一类代表一种「态度」。
| 分类 | 范围 | 含义 | 常见例子 |
|---|---|---|---|
| 1xx | 100-199 | 信息性响应 | 100 Continue |
| 2xx | 200-299 | 成功 | 200 OK, 201 Created |
| 3xx | 300-399 | 重定向 | 301 Moved, 302 Found |
| 4xx | 400-499 | 客户端错误 | 400 Bad, 404 Not Found |
| 5xx | 500-599 | 服务器错误 | 500 Internal, 502 Bad Gateway |
避坑指南：我曾经在联调时遇到一个诡异问题——接口返回200，但数据是错的。后来发现后端把异常也返回200了。所以记住：状态码200不代表业务成功，一定要看响应体里的业务状态码。
我常用的几个状态码，你记一下：
- 200 OK：请求成功，最常见
- 201 Created：创建成功，POST请求常用
- 400 Bad Request：参数错误，多半是你传的格式不对
- 401 Unauthorized：没登录或token过期
- 403 Forbidden：登录了但没权限
- 404 Not Found：接口地址写错了
- 500 Internal Server Error：后端崩了，找后端去
4.3 请求头与响应头：藏在信封上的信息
请求头和响应头，就像信封上的收件人地址和邮戳。你看不到里面的信，但信封上的信息已经告诉了你很多。
4.3.1 常见请求头
| 请求头 | 作用 | 示例 |
|---|---|---|
| Content-Type | 告诉服务器请求体的格式 | application/json |
| Authorization | 携带认证信息 | Bearer eyJhbGci... |
| User-Agent | 标识客户端信息 | Mozilla/5.0... |
| Cookie | 携带会话信息 | session_id=abc123 |
| Accept | 告诉服务器你期望的响应格式 | application/json |
我的经验：做接口测试时，Content-Type最容易出错。你传JSON就得写application/json，传表单就得写application/x-www-form-urlencoded。写错了，后端解析不了，直接给你返回400。
4.3.2 常见响应头
| 响应头 | 作用 | 示例 |
|---|---|---|
| Content-Type | 告诉客户端响应体的格式 | application/json; charset=utf-8 |
| Set-Cookie | 服务器要求客户端设置Cookie | session_id=xyz789; Path=/ |
| Cache-Control | 控制缓存行为 | no-cache, max-age=3600 |
| Access-Control-Allow-Origin | CORS跨域相关 | * |
4.4 知识体系图：HTTP协议核心脉络
下面这张图，是我自己梳理的HTTP协议核心逻辑。你看一遍，基本就串起来了。
4.5 实战：仿真脚本中的HTTP调用
咱们仿真脚本里，最常用的就是GET和POST。我给你看个实际例子：
// 仿真脚本中查询设备状态
GET /api/device/status?deviceId=DEV001 HTTP/1.1
Host: 192.168.1.100:9090
Authorization: Bearer sim_token_2024
Accept: application/json
// 仿真脚本中上报数据
POST /api/device/data HTTP/1.1
Host: 192.168.1.100:9090
Content-Type: application/json
Authorization: Bearer sim_token_2024
{
"deviceId": "DEV001",
"timestamp": "2024-01-15T10:30:00Z",
"temperature": 25.6,
"humidity": 68.2
}关键点：仿真脚本里，Authorization头一定要带上。我见过有人忘了加token，结果接口一直返回401，排查了半天才发现是认证问题。另外，Content-Type写错了，后端解析不了JSON，直接返回400。
嗯，HTTP协议基础就这些。你把这些搞懂了，接口联调时至少能看懂服务器在「说什么」。下次遇到问题，先看状态码，再看响应头，最后看响应体——这个排查顺序，我用了好多年，基本没出过岔子。