HTTP 方法速查表 - REST/HTTP 请求动词与幂等性大全
HTTP 方法难的不是记定义，而是判断一次具体操作该用哪个动词，以及重试和并发下会不会出事。本表按语义分组，把每个方法的幂等性、安全属性、请求体习惯和对应状态码放在一起对照，重点区分几组真正会咬人的组合：PUT 是全量替换，漏传字段等于删除，而 PATCH 只改你传的部分；POST 不幂等，重试会造出重复订单，必须配幂等键；GET 与 HEAD 是安全方法，一旦在里面写状态就不符合语义，也会被浏览器和代理预取放大。判断用法的实操标准有两条：接口上线前先问"客户端重试一次会不会多出一条数据"，会则必须做幂等设计；再问"这个操作能否只描述差异"，不能就用全量替换。与状态码表的分工是，那张表管返回什么，这张表管为什么选这个动词。
核心方法 Core Methods 7
GETPOSTPUTPATCHDELETEHEADOPTIONS幂等与安全性 Idempotency & Safety 4
安全方法幂等方法非幂等Idempotency-Key状态码搭配 Status Pairing 6
GET → 200 / 304POST → 201 / 202PUT → 200 / 204PATCH → 200 / 204DELETE → 204 / 200方法不允许 → 405常见误用 Mistakes 4
用 GET 改状态PUT 当 PATCH 用POST 重复提交DELETE 返回 200 带正文REST 设计约定 6
GET /usersGET /users/1POST /usersPUT /users/1PATCH /users/1DELETE /users/1提示
- PUT 传完整资源，缺字段会被清空；只想改部分用 PATCH。
- GET/HEAD/OPTIONS 是安全方法，不要在其中改服务器状态。
- POST 重试要带 Idempotency-Key，否则可能重复创建资源。
- HTTP 状态码速查表已单独提供，设计接口时配合本表一起看。
- PUT 响应体回不回新资源有分歧：REST 规范允许 200 或 204，但若前端依赖返回值做乐观更新就必须回 200 并带完整资源，团队内要统一选一种。
- 并发更新用 ETag/If-Match 做乐观锁比自造 version 字段更标准：读接口返回 ETag，客户端改完带 If-Match，不匹配返 412 Precondition Failed。
- DELETE 删不存在的资源按语义应幂等，但若业务上"删了要知道原来是什么"就得查库并回 200，退化成 POST 语义时要明确写进接口文档。
常见问题
http 302 和 307 重定向有什么区别?
两者都是临时重定向，但 302 允许浏览器把 POST 改成 GET（历史上很多实现这么做），307 明确定义要保持原方法与请求体，POST 仍是 POST。301 是永久移动并常把方法改为 GET；要在不丢失语义的前提下保留 POST body，用 307。
http 里 PUT 和 PATCH 到底该用哪个?
PUT 是整资源替换：客户端提交完整表示，缺失字段会被当作清空，且幂等，重复请求结果相同。PATCH 做局部更新，只传要改的字段，允许部分内容，但不保证幂等。设计增量更新接口用 PATCH，全量覆盖或创建用 PUT。
GET 请求可以带请求体吗?
规范允许 GET 带 body，但实际很少可靠：代理、缓存、CDN 可能忽略或丢弃它，且 GET 要求无副作用、可缓存。需要传复杂查询就用 URL 查询参数，数据过长或含敏感结构时改用 POST。别依赖 GET body 这种脆弱约定。
http 幂等性是什么意思，哪些方法幂等?
幂等指同一请求执行一次与执行多次，服务端状态都一致，重复发送无害。GET、PUT、DELETE、HEAD、OPTIONS 是幂等的；POST 不幂等，连续提交会创建多条资源。因此自动重试只能作用于幂等请求，POST 需要靠唯一幂等键等方式去重。
接口返回 404 还是 405，怎么区分?
404 是资源不存在（路径写错或资源已删除），405 是资源存在但方法不被支持（如对只读资源发 DELETE），返回 405 时应带 Allow 头列出允许的方法。路径错误给 404，方法用错给 405；清晰区分更利于联调，部分 API 出于安全边界两种都返回 404。
由 巧匠 维护
公开更新于 2026年8月2日，内容持续校对官方文档。