核心概览
这些方法可以大致分为三类:
- 安全方法 :
GET,HEAD,OPTIONS,TRACE。它们只用于获取信息,不应改变服务器状态。 - 非安全方法 :
POST,PUT,PATCH,DELETE。它们旨在改变服务器状态。 - 幂等方法 :
GET,HEAD,PUT,DELETE,OPTIONS,TRACE。多次连续、相同的请求与单次请求效果相同(PATCH和POST通常不是幂等的,但可以设计成幂等)。
详细方法解析
1. GET
- 语义 :检索/获取资源。用于从服务器获取数据,而不产生任何副作用。
- 场景 :
- 获取用户信息:
GET /api/users/123 - 获取文章列表(带分页/过滤):
GET /api/articles?page=2&category=tech - 下载文件。
- 获取用户信息:
- 特点 :
- 安全的
- 幂等的
- 参数通过URL(查询字符串)传递,不应有请求体。
- 响应可被缓存。
2. HEAD
- 语义 :与
GET完全相同,但服务器只返回响应头,不返回响应体。 - 场景 :
- 检查资源是否存在,而无需传输整个内容。
- 检查资源是否被修改 (通过
Last-Modified或ETag头),用于缓存验证。 - 获取资源的元信息(如大小、类型)。
- 特点 :
- 安全的
- 幂等的
3. POST
- 语义 :创建 新资源或提交数据以触发一个可能不严格遵循CRUD的操作。
- 场景 :
- 创建新资源 :创建新用户
POST /api/users(请求体包含用户数据)。 - 执行操作 :用户登录
POST /api/login、支付确认、批量删除(虽然删除用DELETE,但批量操作有时用POST)。 - 文件上传。
- 创建新资源 :创建新用户
- 特点 :
- 非安全的
- 非幂等的(多次调用会创建多个资源或触发多次操作)
4. PUT
- 语义 :完整更新/替换 一个已存在的资源。客户端需要提供资源的完整表示。
- 场景 :
- 更新用户全部信息:
PUT /api/users/123(请求体包含用户的完整新数据)。 - 如果资源不存在,且API支持,也可以用于创建资源(客户端指定ID)。
- 更新用户全部信息:
- 特点 :
- 非安全的
- 幂等的(多次完整替换,结果不变)
5. PATCH
- 语义 :部分更新一个已存在的资源。客户端只需提供需要修改的字段。
- 场景 :
- 只更新用户的邮箱:
PATCH /api/users/123(请求体为{"email": "new@email.com"})。 - 标记订单为已发货(只修改状态字段)。
- 只更新用户的邮箱:
- 特点 :
- 非安全的
- 幂等性取决于实现 。标准要求PATCH也应是幂等的,但需要服务器端逻辑保证(例如,
"age": 25设置多次结果相同,但"score": +1就不是幂等的)。
- 注意 :
PUT和PATCH的关键区别在于,PUT是替换 ,PATCH是修改。
6. DELETE
- 语义 :删除指定的资源。
- 场景 :
- 删除一篇文章:
DELETE /api/articles/456 - 删除一个用户。
- 删除一篇文章:
- 特点 :
- 非安全的
- 幂等的(第一次删除后资源消失,后续请求结果一致------资源已不存在)
7. OPTIONS
- 语义 :用于查询服务器支持的对特定资源的所有HTTP方法。
- 场景 :
- CORS(跨域资源共享)预检请求 :浏览器在发送非简单请求(如PUT、DELETE或带自定义头的请求)前,会自动发送一个
OPTIONS请求,询问服务器是否允许该跨域请求。 - 查看API的能力:
OPTIONS /api/users可能返回Allow: GET, POST, HEAD, OPTIONS。
- CORS(跨域资源共享)预检请求 :浏览器在发送非简单请求(如PUT、DELETE或带自定义头的请求)前,会自动发送一个
- 特点 :
- 安全的
- 幂等的
8. TRACE
- 语义 :用于回显客户端发出的请求。服务器会返回收到的原始请求,主要用于诊断和测试。
- 场景 :
- 诊断请求在到达服务器的路径中是否被中间代理服务器修改。
- 测试网络路径。
- 特点 :
- 安全的
- 幂等的
- 注意 :由于可能被用于跨站跟踪(XST) 攻击,通常在生产环境中会被服务器禁用。
总结表格
| 方法 | 语义 | CRUD | 安全 | 幂等 | 主要场景 |
|---|---|---|---|---|---|
| GET | 检索 | Read | 是 | 是 | 获取数据、查询列表 |
| HEAD | 检索元数据 | Read | 是 | 是 | 检查存在性、验证缓存 |
| POST | 创建/提交 | Create | 否 | 否 | 创建新资源、执行操作 |
| PUT | 完整更新/替换 | Update | 否 | 是 | 更新整个资源 |
| PATCH | 部分更新 | Update | 否 | 应实现 | 更新资源的部分字段 |
| DELETE | 删除 | Delete | 否 | 是 | 删除资源 |
| OPTIONS | 查询支持的方法 | - | 是 | 是 | CORS预检、发现API能力 |
| TRACE | 回显请求 | - | 是 | 是 | 诊断、测试(生产环境少用) |
最佳实践
- 遵循语义:正确使用方法是良好API设计的基础。不要用GET去删除数据。
- 幂等性设计:确保GET、PUT、DELETE的幂等性,并尽可能将PATCH设计为幂等的。对于POST,在关键业务(如支付)上通过Token等机制实现幂等。
- 善用状态码:使用正确的HTTP状态码来反映操作结果(如200 OK, 201 Created, 204 No Content, 404 Not Found)。
- 明确PUT和PATCH:在设计API时,明确区分是要求客户端提供完整资源还是部分更新,并在文档中说明。
- 理解CORS:前端开发中,OPTIONS方法在跨域请求时至关重要。
掌握这些方法的区别和适用场景,是成为一名优秀的后端开发者或API设计师的关键一步。
新建会话