HTTP 请求方法

HTTP 请求方法（又称"动词"）告诉服务器这次请求想干什么——是取数据、建数据、改数据还是删数据。这一章把 9 种方法一次说清，重点对比 5 个常用方法。

1. 方法总览

HTTP/1.1 一共定义了 9 个方法（前 5 个最常用）：

GET：获取资源
POST：新建资源 / 提交数据
PUT：整体替换资源
PATCH：局部修改资源
DELETE：删除资源
HEAD：只取响应头（不要 body）
OPTIONS：查询服务器支持的方法 / CORS 预检
TRACE：回显请求（调试用，默认关闭，有安全风险）
CONNECT：建立隧道（HTTPS 代理时用）

2. GET — 取数据

GET 是最常见的方法，用来读取资源。它的参数必须放在 URL 的查询串里（query string），没有请求体（虽然协议不禁止，但实践中别这么干，会被各种代理/缓存/浏览器搞坏）。

# GET 取数据 — 参数在 URL 查询串里
GET /api/users?role=admin&active=true HTTP/1.1
Host: api.example.com
Accept: application/json

# 等价的 curl:
curl 'https://api.example.com/api/users?role=admin&active=true'

# 等价的 fetch:
fetch('/api/users?role=admin&active=true')

注意 URL 有长度上限（浏览器约 2K~8K 字符），不要用 GET 传大段内容。

3. POST — 新建数据

POST 用于提交数据让服务器创建新资源（如注册用户、发帖、提交订单）。数据放在请求体里，类型由 Content-Type 描述（详见第 6 篇）。

# POST 新建资源 — 数据在请求体里
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 36

{"name":"Bob","email":"b@x.com"}

# 等价的 curl:
curl -X POST https://api.example.com/api/users \
  -H 'Content-Type: application/json' \
  -d '{"name":"Bob","email":"b@x.com"}'

# 等价的 fetch:
fetch('/api/users', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ name: 'Bob', email: 'b@x.com' })
})

POST 的响应通常是 201 Created，并在响应体或 Location 头里返回新资源的 URL。

4. PUT — 整体替换

PUT 用于整体替换一个资源：客户端传什么，服务器最终就长什么样。没传的字段会被清空。PUT 要求客户端提供完整资源。

# PUT 整体替换 — 客户端提供完整资源
PUT /api/users/42 HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 51

{"id":42,"name":"Bob II","email":"b2@x.com"}

# 服务器: 整条记录被替换,没传的字段会被清空
# 幂等: 同样的 PUT 发 100 次,服务器状态都一样

5. PATCH — 局部修改

PATCH 是"只改你传的字段"——其他字段保持不变。这是它和 PUT 最大的区别。

# PATCH 局部更新 — 只改客户端传的字段
PATCH /api/users/42 HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 22

{"email":"new@x.com"}

# 服务器: 只改 email,name/id 保持不变
# 不像 PUT 会清空没传的字段

实战中大部分"修改资料"接口用 PATCH 更合适（用户只想改邮箱，没必要把姓名/年龄全部重传一遍），但很多老项目图省事统一用 PUT。

6. DELETE — 删除

DELETE 删除指定资源。请求体可有可无（实战中通常没有），需要认证（不能让任何人都删数据）。

# DELETE 删除资源
DELETE /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer <token>

# 等价的 curl:
curl -X DELETE https://api.example.com/api/users/42 \
  -H 'Authorization: Bearer <token>'

# 通常是 204 No Content (空响应体) 或 200 + 成功消息

7. HEAD — 只要头不要 body

HEAD 和 GET 完全一样，除了服务器不返回 body。常用于：

检查资源是否存在（200 还是 404）；
看资源大小（Content-Length）；
看最后修改时间（Last-Modified），决定要不要重新下载。

# HEAD 只取头,不要 body
HEAD /api/users/42 HTTP/1.1
Host: api.example.com

# 响应: 只有头,没有 body
# HTTP/1.1 200 OK
# Content-Type: application/json
# Content-Length: 51
# (没有 body)
#
# 用途: 检查资源是否存在、看大小、看最后修改时间,不浪费流量下载 body

8. OPTIONS — 探测与 CORS 预检

OPTIONS 用来问服务器"你这个 URL 支持哪些方法"。浏览器在做跨域请求（CORS）且带自定义头/非简单方法时，会自动先发一个 OPTIONS 预检，服务器响应里通过 Access-Control-Allow-* 头告诉浏览器是否允许实际请求。

# OPTIONS 探测服务器支持哪些方法
OPTIONS /api/users HTTP/1.1
Host: api.example.com
Origin: https://www.example.com

# 响应:
# HTTP/1.1 204 No Content
# Allow: GET, POST, OPTIONS
# Access-Control-Allow-Methods: GET, POST, PUT, DELETE
#
# 浏览器 CORS 预检请求就用的 OPTIONS,详见下文

9. 安全与幂等：两个核心概念

这是面试高频题，也是设计 RESTful API 的关键依据：

安全（Safe）：方法不改服务器数据。GET/HEAD/OPTIONS 是安全的，POST/PUT/DELETE 都不安全。
幂等（Idempotent）：同一请求重复发 N 次，服务器的最终状态和发 1 次一样。PUT/DELETE/GET/HEAD/OPTIONS 是幂等的，POST 和 PATCH 不幂等。

# 安全 (Safe): 不改服务器状态 → GET, HEAD, OPTIONS
# 幂等 (Idempotent): 同一请求发 N 次,服务器状态相同 →
#   GET, HEAD, OPTIONS, PUT, DELETE
# 不幂等: POST, PATCH
#
# 实战含义:
#   - 浏览器对 GET 会被缓存/重试 (后退不警告)
#   - POST 重发会弹"确认重新提交表单"

这就是为什么浏览器"刷新"一个 POST 结果页会弹"确认重新提交表单"——因为 POST 不幂等，再发一次可能在服务器又新建一条记录（重复下单、重复发帖）。GET 没这个问题。

10. RESTful API 怎么映射方法

RESTful 风格把每个 URL 当作一个"资源"，方法当作"操作"，组合起来语义清晰：

GET /users → 列出所有用户
POST /users → 新建一个用户
GET /users/42 → 获取 id=42 的用户
PUT /users/42 → 整体替换 id=42
PATCH /users/42 → 局部更新 id=42
DELETE /users/42 → 删除 id=42

11. 方法被覆盖：X-HTTP-Method-Override

有些老浏览器/HTML 表单只能发 GET 和 POST。为了能用 PUT/DELETE，约定在请求头加 X-HTTP-Method-Override: PUT，服务器据此把 POST 当 PUT 处理。现代前后端分离项目基本用不上，但知道有这回事。

小结

记住一句话：读用 GET，建用 POST，整体改用 PUT，局部改用 PATCH，删用 DELETE。GET/HEAD 安全且幂等，PUT/DELETE 幂等但不安全，POST/PATCH 既不安全也不幂等。

← 上一篇 HTTP 报文结构

下一篇 HTTP 状态码 →

✈️💬