已经有了get、post，为什么还要用put、patch、delete？以及如果一个接口同时需要对数据库有增删改查（crud）的操作，该使用那种请求方式

本文链接：https://blog.csdn.net/2403_88969259/article/details/144510851

1. GET 请求

适用场景：当接口的目标是获取资源或查询信息时，使用 GET 请求。适合通过过滤、排序、分页等方式查询数据。GET 请求通常不需要请求体，仅通过 URL 和查询参数来传递信息。
理由：GET 方法的语义明确，专注于查询操作，且不会对服务器产生副作用（幂等性）。它的 URL 可被缓存、书签化或共享，符合 RESTful API 的最佳实践。
请求示例：

json

代码解读

复制代码

GET /api/resource/123

2. POST 请求

适用场景：如果这个接口是以“提交一组操作”或“批量处理”为目标（比如批量更新某个资源集合），通常使用 POST 请求。
理由：POST 通常用于创建或提交复杂的操作。它没有幂等性要求，因此适合包含多个操作的请求。
请求示例：

json

代码解读

复制代码

POST /api/resource/batch-operation Content-Type: application/json { "create": [ {"name": "New Item 1", "value": "Value 1"}, {"name": "New Item 2", "value": "Value 2"} ], "update": [ {"id": 1, "name": "Updated Item", "value": "Updated Value"} ], "delete": [2, 3] }

3. PATCH 请求

适用场景：如果主要目标是对某个资源集合进行部分更新，同时允许新增和删除元素。
理由：PATCH 表示对资源的部分修改，适合增删改操作，但在语义上比 POST 更专注于更新。
请求示例：

json

代码解读

复制代码

PATCH /api/resource Content-Type: application/json { "create": [ {"name": "New Item 1", "value": "Value 1"} ], "update": [ {"id": 1, "name": "Updated Item", "value": "Updated Value"} ], "delete": [2] }

4. PUT 请求

适用场景：如果整个资源集合需要被“替换”或者以新的状态“覆盖”，可以使用 PUT。
理由：PUT 用于资源的完全替换，但需要客户端提供完整的资源状态信息。
请求示例：

json

代码解读

复制代码

PUT /api/resource Content-Type: application/json { "data": [ {"id": 1, "name": "Updated Item", "value": "Updated Value"}, {"name": "New Item", "value": "Value"} ] }

5. DELETE 请求

适用场景：当接口的目标是删除资源或撤销某些操作时，使用 DELETE 请求。它适用于删除单一资源或批量删除多个资源。
理由：DELETE 方法语义清晰，明确表示删除操作，与 RESTful 风格中资源的删除场景自然对应。它具有幂等性，确保多次调用不会导致意外行为。
请求示例：

json

代码解读

复制代码

DELETE /api/resource?status=inactive

6. 自定义操作

适用场景：如果逻辑复杂或者不属于 RESTful 风格，可以考虑定义一个明确的操作接口，比如 /batch-operate 或 /multi-action。
请求示例：

json

代码解读

复制代码

POST /api/resource/multi-action Content-Type: application/json { "operations": [ {"type": "create", "data": {"name": "New Item 1", "value": "Value 1"}}, {"type": "update", "data": {"id": 1, "name": "Updated Item", "value": "Updated Value"}}, {"type": "delete", "data": {"id": 2}} ] }