接口同时有 crud 的操作时，该使用 post 还是 put 请求？

前言

对于同时涉及 查询、新增、修改 和 删除 操作的接口请求，一般有以下几种选择，具体取决于你的业务需求和接口设计风格。

这里我对一些常用的请求方式，使用场景和理由做一个简单的说明。

1. GET 请求

• 适用场景：当接口的目标是获取资源或查询信息时，使用 GET 请求。适合通过过滤、排序、分页等方式查询数据。GET 请求通常不需要请求体，仅通过 URL 和查询参数来传递信息。

• 理由：GET 方法的语义明确，专注于查询操作，且不会对服务器产生副作用（幂等性）。它的 URL 可被缓存、书签化或共享，符合 RESTful API 的最佳实践。

• 请求示例：

GET /api/resource/123

2. POST 请求

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

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 更专注于更新。
• 请求示例：

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 用于资源的完全替换，但需要客户端提供完整的资源状态信息。
• 请求示例：

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 风格中资源的删除场景自然对应。它具有幂等性，确保多次调用不会导致意外行为。
• 请求示例：

DELETE /api/resource?status=inactive

6. 自定义操作

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

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}}
  ]
}

推荐方案：

（一个接口增删改查都有的情况）

• 优先考虑 POST，因为它表达的是一种“操作提交”，适合批量和复杂操作。
• 接口设计提示：
  1. 确保操作的请求体具有明确的结构，以便客户端和服务端都能解析。
  2. 通过响应体清晰地返回各类操作的成功或失败状态。
  3. 如果可能，尽量保证幂等性，例如同样的请求多次执行结果一致（至少对于删除和更新操作）。

这样设计接口既灵活又具备扩展性，可以很好地满足增删改的混合需求。