HTTP 协议中定义了多种 请求方法（HTTP Methods），用于客户端和服务器之间进行不同的操作。
一、常用的 HTTP 方法#
| 方法 | 是否幂等 | 是否安全 | 说明 |
|---|
| GET | ✅ 幂等 | ✅ 安全 | 获取资源。请求参数放在 URL 上。不会对资源产生副作用。 |
| POST | ❌ 非幂等 | ❌ 不安全 | 提交数据（如表单、上传），可能导致资源变化或创建。 |
| PUT | ✅ 幂等 | ❌ 不安全 | 用于整体更新某个资源（数据完全替换）。 |
| PATCH | ❌ 非幂等 | ❌ 不安全 | 用于部分更新资源（只改动部分字段）。 |
| DELETE | ✅ 幂等 | ❌ 不安全 | 删除指定资源。 |
二、幂等性和安全性解释#
- 幂等（Idempotent）：同一个请求重复执行多次，结果应一样。例如多次 DELETE 相同资源结果相同。
- 安全（Safe）：不对服务器资源造成副作用。GET 只查询，不修改数据，因此是安全的。
三、其他常见 HTTP 方法#
| 方法 | 说明 |
|---|
| HEAD | 类似 GET，但不返回响应体，只返回响应头。常用于检测资源是否存在、获取响应信息。 |
| OPTIONS | 用于客户端获取服务器支持哪些方法。也是 CORS 预检请求的一部分。 |
| TRACE | 回显服务器收到的请求，主要用于调试。很少使用，可能存在安全隐患。 |
| CONNECT | 用于建立隧道（如 HTTPS 的代理通信）。 |
四、使用场景示例#
| 场景 | 方法 | 示例 |
|---|
| 获取用户列表 | GET | GET /api/users |
| 创建用户 | POST | POST /api/users |
| 更新用户信息 | PUT / PATCH | PUT /api/users/1 或 PATCH /api/users/1 |
| 删除用户 | DELETE | DELETE /api/users/1 |
总结：记住这几点#
- GET 用于查询（安全、幂等）。
- POST 用于新增（不幂等）。
- PUT/PATCH 用于修改资源（PUT 是整体替换，PATCH 是部分更新）。
- DELETE 用于删除资源（幂等，但不安全）。
- OPTIONS/HEAD 用于辅助请求。
常见考点#
1. 语义理解#
- 每个方法在 RESTful API 中代表的含义？
- PUT 和 PATCH 的区别？
- GET 和 POST 区别？是否可以用 POST 替代 GET？
2. 幂等性与安全性#
- 哪些方法是幂等的？（调用多次结果一致）
- 哪些方法是安全的？（不会对服务器资源产生副作用）
3. 浏览器行为#
- 表单默认提交方式是什么？（GET 或 POST）
- GET 请求能携带 body 吗？（规范上不能，但部分浏览器允许）
4. 缓存行为#
- 浏览器对 GET、POST 的缓存行为有什么区别？
- 为什么 GET 更适合缓存？
5. 跨域相关（CORS）#
- 哪些方法属于“简单请求”？
- 使用 PUT/PATCH/DELETE 会触发预检请求（OPTIONS），为什么？
6. 请求体与响应体#
- 哪些方法通常不携带请求体？（如 GET、DELETE）
- 哪些方法可以/需要携带请求体？（如 POST、PUT、PATCH）
7. 对比和实际使用中的陷阱#
- PUT/POST 混用的场景（如某些系统用 POST 实现更新）
- DELETE 是否要有请求体？（规范允许，但不推荐）
可能的延伸考察#
RESTful API 设计规范#
- REST API 中，如何正确使用 GET/POST/PUT/DELETE 等方法？
- 设计一个增删改查接口，如何对应到不同 HTTP 方法？
状态码与方法配合#
- DELETE 成功一般返回什么状态码？（如 204 No Content）
- POST 创建资源后返回什么？（201 Created）
结合安全问题#
- POST/PUT 方法可能面临哪些安全风险？如 CSRF？
- 为什么建议对非幂等方法加 CSRF 防护？