REST API设计疑问：无请求体的数据库修改接口用PUT还是GET？

核心原则：绝对不能用GET #

GET请求的HTTP语义是安全且无副作用的——调用它不应该改变服务器上的任何状态。如果用GET来修改数据库，会引发一系列问题：比如浏览器缓存GET请求、爬虫自动触发、用户刷新页面重复执行修改，完全违反HTTP规范。所以直接排除GET选项。

为什么PUT不合适（当前场景） #

PUT的语义是完整替换目标资源，要求客户端提供资源的完整表示。你的场景里，新值由端点隐含确定，客户端没有发送完整的资源内容，这和PUT的核心语义不匹配。强行用PUT会让API语义模糊，其他开发者看到PUT会默认客户端要提交完整资源，增加理解成本。

推荐的两种方案 #

方案1：使用POST（最直观） #

POST适合处理触发状态变更或动作类的操作，尤其是当修改逻辑由服务器端点隐含定义时。可以设计语义化的端点，让意图一目了然：

• 示例：如果是标记订单为已完成，端点可设为 POST /orders/{orderId}/mark-as-completed
• 优势：语义清晰，其他开发者一看就知道这个调用会触发“标记完成”的动作；POST允许无请求体（符合你的场景），且天然支持有副作用的操作。

方案2：使用PATCH（适合部分更新场景） #

如果这个修改可以被描述为资源的部分属性更新，你可以用PATCH配合JSON Patch格式来定义操作。即使客户端不直接传值，也可以在请求体里明确描述要修改的属性和目标值（该值可由服务器验证）：

• 示例：PATCH /orders/{orderId}，请求体为：

  [{"op": "replace", "path": "/status", "value": "completed"}]
  

• 优势：符合REST的部分更新语义，适合需要明确修改字段的场景；如果后续需要扩展参数，也更容易兼容。

补充：幂等性的考量 #

如果你的操作是幂等的（重复调用多次结果完全一致，比如重复标记已完成的订单），也可以考虑设计成PUT到子资源（比如 PUT /orders/{orderId}/status，请求体携带"completed"），但前提是客户端要发送目标值——这和你当前“新值由端点隐含”的场景不太匹配，所以优先级低于前两种方案。

内容的提问来源于stack exchange，提问作者Sally Goldin