最核心和常用的方法有以下几个:
-
GET
-
用途:请求指定的资源。只用于获取数据,不应产生任何“副作用”(如修改数据)。
-
特点:请求的参数直接附加在 URL 后面(查询字符串 Query String),有长度限制,且会被浏览器历史记录保存。可以被缓存、收藏为书签。
-
-
POST
-
用途:提交数据给服务器,通常会导致服务器状态的变化(如创建新资源)。
-
特点:数据放在请求体(Request Body)中发送,没有长度限制,也更安全(不会显示在 URL 或浏览器历史中)。通常不会被缓存。
-
-
PUT
-
用途:更新指定资源的所有内容。如果资源不存在,可以用 PUT 来创建它。
-
特点:请求体中包含资源完整的更新后版本。是幂等的(多次执行同样的 PUT 操作,结果都是相同的)。
-
-
DELETE
-
用途:删除指定的资源。
-
特点:操作是幂等的。
-
-
PATCH
-
用途:部分更新指定的资源。与 PUT 不同,PATCH 只提交需要修改的字段,而不是整个资源。
-
特点:请求体中包含一组指令,描述如何修改资源。不是幂等的(取决于实现方式,但标准定义下,连续相同的 PATCH 请求可能产生不同结果)。
-
二、其他不常用但重要的方法
-
HEAD
-
用途:与 GET 方法类似,但服务器只返回响应头,不返回响应体。用于在下载大文件前检查其元数据(如大小、类型)或验证链接有效性。
-
-
OPTIONS
-
用途:询问服务器对于某个 URL 支持哪些请求方法。常用于 CORS(跨域资源共享) 预检请求中。
-
-
CONNECT
-
用途:建立一个到目标资源的隧道,通常用于通过代理服务器建立 SSL 加密通道。
-
-
TRACE
-
用途:沿着到目标资源的路径执行一个消息环回测试,主要用于诊断。由于存在安全风险(如 XST 攻击),通常被浏览器禁用。
-
三、核心区别对比表
方法 | 语义(目的) | 是否幂等 | 是否安全 | 请求体 | 典型应用场景 |
---|---|---|---|---|---|
GET | 获取/查询资源 | 是 | 是 | 通常无 | 访问网页、搜索、点击链接 |
POST | 提交/创建资源 | 否 | 否 | 有 | 用户登录、提交表单、上传文件 |
PUT | 完整更新/创建资源 | 是 | 否 | 有 | 更新用户个人资料(提供完整信息) |
PATCH | 部分更新资源 | 通常否 | 否 | 有 | 只修改用户的昵称或状态 |
DELETE | 删除资源 | 是 | 否 | 通常无 | 删除一篇文章、一个用户 |
HEAD | 获取资源的元信息 | 是 | 是 | 无 | 检查链接是否有效、资源是否更新 |
OPTIONS | 查询服务器支持的方法 | 是 | 是 | 无 | CORS 预检请求 |
四、关键概念解释
1. 安全性(Safe Methods)
一个方法是“安全”的,意味着它只用于读取信息,而不会修改服务器上的任何数据。GET、HEAD、OPTIONS 被认为是安全的方法。安全的方法可以被缓存、预加载,而不会产生意外后果。
注意:安全不代表操作没有副作用(如记录日志),只是说用户的意图不是修改数据。
2. 幂等性(Idempotent Methods)
一个方法是“幂等”的,意味着相同的请求被执行一次与连续执行多次的效果是一样的(服务器状态端)。
-
GET:多次获取同一资源,结果不变。(幂等)
-
PUT:用同样的数据多次更新同一资源,结果与一次更新相同。(幂等)
-
DELETE:删除一个资源后,再次删除,结果依然是“已删除”。(幂等)
-
POST:提交一次订单会创建一个新订单,提交两次会创建两个订单。(不幂等)
幂等性对网络通信非常重要,当请求失败时(如超时),客户端可以安全地重试幂等的请求,而不用担心产生意外效果。
总结
-
RESTful API 设计 的核心就是充分利用这些 HTTP 方法的语义。
-
GET /users
- 获取用户列表 -
POST /users
- 创建一个新用户 -
GET /users/1
- 获取 ID 为 1 的用户 -
PUT /users/1
- 更新 ID 为 1 的用户(完整信息) -
PATCH /users/1
- 更新 ID 为 1 的用户(部分信息) -
DELETE /users/1
- 删除 ID 为 1 的用户
-
理解这些方法的区别和适用场景,是进行 Web 开发和 API 设计的基础。