HTTP 方法完整参考表

HTTP 方法（HTTP Methods）定义客户端对资源执行的操作。本表覆盖 9 种标准方法，标注安全（Safe）、幂等（Idempotent）、是否携带请求体及典型用途，帮助正确选型。

原理解析

HTTP 方法（动词）表达对资源要执行的「动作语义」。GET 取资源、POST 新建、PUT 整体替换、PATCH 局部修改、DELETE 删除。安全方法（GET/HEAD/OPTIONS）只读取、不改变服务端状态。

幂等性指多次相同请求效果等价于一次：GET/PUT/DELETE 幂等，POST 不幂等（重复提交可能创建多个资源）。RESTful 设计据此约定语义，客户端与网关（缓存、重试）也依赖这些语义。

什么时候该查这张表

这张表在你要选 HTTP 方法、或判断某个接口该用 POST 还是 PUT 时有用。它给出每个方法的安全性与幂等性、是否允许请求体，以及典型语义。多数 REST 争议（POST 能不能当 PUT 用、DELETE 能不能重复调）都能在这张表里找到判据。

不该查的情况：你在设计 API 的业务语义或版本策略。方法选对不等于接口设计对——资源划分、嵌套关系、分页与过滤、错误码体系都是独立课题，一张方法对照表给不出这些答案。

判断标准：先问「这个操作是否改变服务器状态」，再问「重复执行同一请求，结果是否与执行一次相同」。两个都答「否」才是 GET；改变状态且幂等用 PUT/PATCH；改变状态且非幂等用 POST。

特别注意 POST 不是「非幂等」的同义词：POST /login 重复调用会返回同样的结果（已登录），POST /orders 重复调用会创建多笔订单。幂等性由接口设计决定，不由方法名决定，表格给的是最常见约定而非强制规则。

边界与常见陷阱

把 PATCH 当 PUT 用会导致部分更新语义混乱
PUT 要求完整替换资源：请求体没带的字段会被清空或重置为默认值。PATCH 只提交要改的字段。因此「只改用户昵称」的接口用 PUT 会意外把邮箱、头像等未传字段重置。工程上更麻烦的是 PUT 的幂等性只有在实现真的做全量替换时成立——很多框架的 PUT 实际是合并更新，此时 PUT 就不再幂等，客户端重试会造成数据错乱。
安全方法不代表没有副作用
GET /delete-all?id=1 违反规范，但语法上完全合法且多数客户端与浏览器不会阻止。规范定义「安全」只是语义约定，服务端若在 GET 里做了写操作，缓存、预取、爬虫、重试都会放大影响。真正的防护在服务端：写操作只接受 POST/PUT/PATCH/DELETE，GET 处理器里禁止任何数据库写入，并把它写进代码评审清单。
DELETE 的幂等性依赖实现，重复调用要能安全返回
规范要求 DELETE 幂等，即删两次与删一次结果相同。但很多实现第二次会返回 404，而客户端与网关往往把 404 当失败并触发重试风暴。健壮做法：重复 DELETE 仍返回 200/204（或 200 带 alreadyDeleted 标记），而不是 404。配套要求删除操作要设计成软删除或带版本号，保证「重复删同一资源」在语义上真的可重入。
方法决定缓存行为，误用会让改动不生效
GET/HEAD 默认可被缓存，POST/PUT/PATCH/DELETE 默认不可缓存。所以「更新后前端仍看到旧数据」若用 POST 提交，浏览器/CDN 仍会缓存对应的 GET。排查时看响应头 Cache-Control 与 ETag，别只看服务端是否收到写入。同时注意非 GET 响应也可能被缓存（除非显式声明），GET 被 CDN 缓存后即使后端已更新也不会回源。

与相邻内容的分工

要查具体状态码的语义（201 与 200 的区别、502 由谁返回），用站内「HTTP 状态码」页；本页只讲方法选择。

要处理跨域、方法白名单与预检请求，属 CORS 机制范畴，与方法语义是两件事。

要设计接口的版本演进与兼容策略，本表给不出建议，方法一旦发布就很难改。

若目的是排查某个接口的幂等性问题，需要看具体实现与重试逻辑，表里的「幂等」列只是常见约定。

实战片段

要点：① GET 处理器里禁止任何写操作，语义约定挡不住缓存与爬虫；② 幂等性由实现决定不由方法名决定，POST 可以幂等、PUT 若做成合并更新就不再幂等；③ 创建类接口用 POST 要配 Idempotency-Key 防重复提交；④ 局部更新用 PATCH，PUT 是全量替换，混用会静默清空未传字段；⑤ 重复 DELETE 应返回 200/204 而非 404，否则触发客户端重试风暴；⑥ 改完读不到新值时先看 Cache-Control 与 Age，别怀疑写入是否成功。

# ① 只读 vs 写操作：GET 绝不产生副作用
curl -sS https://api.example.com/users            # ✅ 安全
curl -sS -X DELETE https://api.example.com/u/1   # ❌ 用 DELETE，别用 GET 带副作用

# ② 幂等重试演示：GET 重复 3 次结果一致
for i in 1 2 3; do curl -sS https://api.example.com/orders/42; echo; done

# ③ POST 创建：重复调用会创建多笔（所以客户端要带 Idempotency-Key）
curl -sS -X POST https://api.example.com/orders   -H 'Content-Type: application/json'   -H 'Idempotency-Key: 7f3a9c1e'   -d '{"sku":"A1","qty":1}'

# ④ PUT 全量替换 vs PATCH 局部更新
curl -sS -X PATCH https://api.example.com/users/7   -H 'Content-Type: application/json'   -d '{"nickname":"new-name"}'      # ✅ 只改昵称
# 若用 PUT 且只传 nickname ⇒ email/avatar 会被重置为默认值

# ⑤ 观察缓存头（排查「改了却读到旧值」）
curl -sSI https://api.example.com/orders/42 | grep -iE 'cache-control|etag|age'
# Age > 0 ⇒ 命中缓存，解释了为什么改动没立即生效

# ⑥ 405 的正确处理：方法不被允许
curl -sS -X DELETE https://api.example.com/health
# ⇒ 405 Method Not Allowed，响应应带 Allow: GET, HEAD

实践注解

PATCH 不是「POST 的小号」，语义上必须可部分更新PATCH 传的是「变更描述」，未出现的字段应保持不变。很多实现把 PATCH 写成整体覆盖，导致并发下丢失未提交的字段。要整体替换应使用 PUT，要局部更新用 PATCH 并对缺失字段做不动处理。
GET 带 body 会被代理丢弃HTTP 规范未禁止 GET 携带 body，但中间层（部分 CDN、Nginx 默认配置、旧版 fetch 实现）会直接丢掉它。查询条件一律放 query string，别把 JSON 塞进 GET body。
「安全」指的是不改变服务端状态，不等于「无副作用」GET 是安全方法，但仍会在服务端留下访问日志、指标与缓存写入，也可能被预取。因此不要把「确认下单」「注销账号」这类动作挂在 GET 上——浏览器预取与爬虫都可能触发它。

数据来源

RFC 9110 §9 (method definitions, safety and idempotence)

上述编号、名称与定义均来自公开规范，本站不主张对规范数据本身的独创性；本页的编排方式、中文释义与实践注解由本站撰写。

方法	安全	幂等	请求体	说明
GET	是	是	否	获取资源表示，安全且幂等，可被缓存与收藏。
HEAD	是	是	否	同 GET 但不返回主体，仅返回头部（检查存在性/修改时间）。
POST	否	否	是	提交数据处理，常创建子资源，非安全非幂等。
PUT	否	是	是	用完整表示替换整个资源，幂等（重试安全）。
PATCH	否	否	是	对资源做局部修改（仅发送变更字段），非幂等。
DELETE	否	是	可选	删除资源，幂等（反复删同一资源结果一致）。
OPTIONS	是	是	否	查询目标支持的通信选项，常用于 CORS 预检。
CONNECT	否	否	否	建立到服务器的隧道（如通过代理的 HTTPS）。
TRACE	是	是	否	回显收到的请求，用于诊断；有安全风险常被禁用。

常见问题

GET 和 POST 有什么区别？

GET 用于获取资源，参数在 URL 中，安全且幂等，可被缓存和收藏；POST 用于提交数据，参数在请求体，非安全非幂等，默认不被缓存。

PUT 和 PATCH 有什么区别？

PUT 用完整资源表示替换整个目标（幂等）；PATCH 只发送需要修改的字段做局部更新（非幂等）。

什么是幂等（Idempotent）？

同一请求执行一次与多次，对服务端状态的最终影响相同。GET/PUT/DELETE 是幂等的，POST/PATCH 不是。幂等性让客户端在超时后可安全重试。

OPTIONS 方法用来做什么？

返回目标资源支持的 HTTP 方法列表，最常见的用途是 CORS 预检请求，由浏览器在跨域请求前自动发出。