HTTP 方法语义与幂等性
HTTP 方法自带语义契约：GET/HEAD 是安全的（不改变服务端状态）且幂等，PUT/DELETE 幂等（重复执行结果一致），POST 非幂等，PATCH 的幂等性取决于接口定义。测试要按语义验证行为：重复 PUT 不应产生重复资源、重复 DELETE 应平稳返回而不是报错、对非幂等接口的自动重试必须带幂等键。网关、SDK 与客户端的重试策略都建立在这套语义之上。
方法
| 方法 | 安全 | 幂等 | 典型用途 |
|---|---|---|---|
| GET | 是 | 是 | 查询资源 |
| HEAD | 是 | 是 | 仅取元数据 |
| PUT | 否 | 是 | 整体替换 |
| DELETE | 否 | 是 | 删除资源 |
| POST | 否 | 否 | 创建或提交动作 |
| PATCH | 否 | 依定义 | 部分更新 |
基本信息
| 幂等含义 | 同一请求重复执行，服务端最终状态一致 |
|---|---|
| 测试关注 | 重复提交的最终状态、响应码与响应体的一致性 |
| 重试设计 | 只对幂等操作自动重试；非幂等操作需幂等键配合 |
| 常见幂等键 | 客户端生成唯一请求 ID，服务端去重 |
| 语义检查 | 删除后再删、替换后再替换、GET 不产生副作用 |
典型使用场景
- 接口语义评审：新接口上评审会时核对其方法选择是否符合语义。
- 重试策略验证：模拟超时重发，验证幂等接口无副作用。
- 重复提交测试：下单按钮连点与网络重试场景的最终状态核对。
- 网关配置检查：代理层自动重试白名单只覆盖幂等操作。
- SDK 行为测试：客户端库的默认重试逻辑是否按方法区分。
- 资源替换验证：PUT 重复执行后资源版本与内容保持一致。
重复提交验证示例
重复提交验证示例
curl -i -X PUT https://api.example.com/items/42 -d '{"name":"a"}'
curl -i -X PUT https://api.example.com/items/42 -d '{"name":"a"}'
# 两次 PUT：最终应只有一个 42 资源，第二次返回一致的 200/204
curl -i -X POST https://api.example.com/orders -d '{"sku":"A-1"}' -H 'Idempotency-Key: 7f3c...'
# 带幂等键重发：服务端应识别并返回首次结果，而不是再下两单对非幂等接口自动重试而不带幂等键，可能造成重复下单、重复扣款类缺陷。
DELETE 的幂等体现为「重复删除不报 500」：第一次 204、第二次 404 或 204 都合理，但实现约定要与接口文档一致并写进断言。
PATCH 是否幂等由接口定义决定：测试前先确认业务约定，例如「追加备注」类 PATCH 重复执行会叠加内容，属于明确约定而非缺陷。