HTTP协议基础：请求方法、状态码、请求头与响应头
做接口调试，说白了就是在跟HTTP协议打交道。我记得刚入行那会儿，遇到一个接口总报400，我盯着请求报文看了一下午，最后发现是请求头里的Content-Type写错了。嗯，从那以后我就养成了一个习惯——先确认HTTP基础再动手调。
这一章我们就把HTTP协议里最常用的几个点捋清楚。你想想看，密钥审计接口的签名校验、参数传递、错误处理，哪一步离得开这些基础？
请求方法：增删改查的“动词语义”
HTTP请求方法就像是给服务器下指令的动词。我个人习惯把它类比成数据库的CRUD操作——GET就是查，POST就是增，PUT就是改，DELETE就是删。当然实际没那么一刀切，但本质差不多。
| 方法 | 语义 | 是否携带Body | 幂等性 | 密钥审计接口常见场景 |
|---|---|---|---|---|
| GET | 获取资源 | 否 | 是 | 查询密钥列表、获取密钥详情 |
| POST | 创建资源（或执行操作） | 是（JSON/表单） | 否 | 生成新密钥、提交审计报告 |
| PUT | 全量更新资源 | 是（JSON） | 是 | 更新密钥元信息、替换密钥策略 |
| DELETE | 删除资源 | 通常无Body | 是 | 撤销密钥、删除审计记录 |
实战要点：
- 密钥审计接口通常用POST做“申请”和“变更”，因为幂等性要求没那么强；
- 查询类接口尽量用GET，方便缓存和浏览器直接调试；
- 有些密钥管理API用PATCH做部分更新，但PUT用得更多，看团队约定。
我在项目中遇到过开发新人用POST去做纯查询接口的，结果后端解析了body里的查询条件，但每次请求都生成一条新的审计日志……你想想看，这日志量得多壮观？后来我们强制要求：读操作必须用GET，除非有安全原因不能把参数放在URL里。
小提示：用Postman或curl调试时，先确认方法选对了。我曾经在调试一个密钥撤销接口时，用GET请求发了两个小时，一直返回405 Method Not Allowed——嗯，你说尴尬不尴尬？
状态码：服务器在说什么？
状态码就是服务器给你的“回执”，三数字就能告诉你请求是成功、被拒绝、还是崩了。我个人把常见状态码分成三类：
- 2xx 成功族 —
200 OK（常规成功）、201 Created（创建成功，POST常用）、204 No Content（删除成功，无返回体）。 - 4xx 客户端错 —
400 Bad Request（参数错误）、401 Unauthorized（没登录或过期）、403 Forbidden（没权限）、404 Not Found（接口或资源不存在）、422 Unprocessable Entity（语义错误）。 - 5xx 服务端错 —
500 Internal Server Error（服务挂了）、502 Bad Gateway（网关/代理问题）、503 Service Unavailable（过载或维护）。
避坑指南：我曾经遇到一个密钥审计接口，校验签名失败时返回的是200，但body里塞了个错误码。这种做法让监控和网关拦不住异常流量。后来我推动团队改成：认证失败一律401，参数校验失败一律400，业务逻辑失败才用200+业务码。这么改之后，报警准确率高出不少。
举个例子，你请求一个密钥详情：
# 请求
GET /api/v1/keys/k-abc123
Authorization: Bearer <>
# 成功响应
HTTP/1.1 200 OK
{
"keyId": "k-abc123",
"status": "active",
"createdAt": "2025-03-01T10:00:00Z"
}
# 密钥不存在
HTTP/1.1 404 Not Found
{
"error": "Key not found"
}
# 过期
HTTP/1.1 401 Unauthorized
{
"error": " expired"
}
小提示：调试时优先看状态码，别一头扎进body。400还是401？一眼就知道是谁的锅——是前端参数错了，还是后端认证有问题。
请求头与响应头：元数据的“暗号”
请求头和响应头就像是快递包裹上的标签——表面看不见商品，但配送地址、重量、签收确认全靠它。密钥审计接口里最常见的头包括：
| 头部名称 | 方向 | 作用 | 常见取值 |
|---|---|---|---|
| Content-Type | 请求/响应 | 声明body的格式 | application/json application/x-www-form-urlencoded |
| Authorization | 请求 | 携带认证凭据（、签名） | Bearer <> HMAC-SHA256 <signature> |
| Accept | 请求 | 告诉服务器客户端能接收的格式 | application/json |
| X-Request-Id | 请求/响应 | 链路追踪ID，方便排查问题 | uuid |
| X-Timestamp | 请求 | 请求时间戳，防重放攻击 | Unix毫秒时间戳 |
拿密钥审计接口最常见的签名校验来说，你需要把请求头里的Authorization和X-Timestamp一起验签。我建议你在调试时先打印出所有原始请求头，防止中间代理偷偷改动了什么。
实战要点：
- 密钥审计接口的
Content-Type一定是application/json，除非是文件上传； - 签名用的
Authorization头不要写死，每次请求重新计算； - 响应头里的
X-RateLimit-Remaining能告诉你是不是被限流了，别忽略。
记得有一次，我在调一个第三方密钥审计服务，始终返回403。检查了半天，发现是请求头里少了一个X-Partner-Id的自定义头。嗯，这就是不看文档的代价。
避坑指南：我曾经因为Content-Type写成了text/plain而body里塞了JSON，结果服务器返回400说解析失败。这个错误低级但极其常见——尤其当你复制别人代码没改header的时候。
小结一下
这一章我们把HTTP协议的三个核心维度拆开了：请求方法决定了怎么“说话”，状态码告诉你“话说得对不对”，请求头/响应头则负责“递小纸条”传递元信息。密钥审计接口的参数校验，说白了就是检查这些东西拼得对不对、签得对不对、传得对不对。