在设计 Restful API 时，我应该使用 DELETE 还是 POST 来取消关注？

Posted 2023-03-31

【中文标题】在设计 Restful API 时，我应该使用 DELETE 还是 POST 来取消关注？

【英文标题】：When designing Restful API, should I use DELETE or POST for UNFOLLOW?

【发布时间】：2019-09-29 19:32:29

【问题描述】：

我脑子里想了一天这个问题，我尝试阅读 RESTful Web Services Cookbook 和其他 *** 帖子，但仍然没有得到这个问题的令人信服的答案：

假设我有一个存储两个用户之间关系的数据库表，该关系表示如果用户 A 正在关注用户 B（例如在 Instagram/Twitter 上）。

userId|userId
------|------
userA | userB
userA | userC
....

那么现在如果用户A想取消关注用户B，那么这个API应该是DELETE还是POST？

在 RESTful Web Services Cookbook 第 11 页中，它说：

"DELETE 方法是幂等的。这意味着即使服务器在先前的请求中删除了资源，服务器也必须返回响应代码 200 (OK)。但实际上，将 DELETE 实现为幂等操作要求服务器跟踪所有已删除的资源。否则，它可以返回 404（未找到）。"

这是否建议我们尽可能避免使用DELETE？

感谢您对这个问题的任何见解！

【参考方案1】：

DELETE 用于删除特定资源。因此，DELETE 是否适合您取决于您​​是否拥有一个“代表”两个用户之间的关注关系的资源。

例如，如果您有这样的资源：

/api/userA/follows/userB

那么可以说这个资源代表了两者的关系。它有一个唯一的 url，所以这个 url 可以被删除，我希望这种关系会被切断。

【参考方案2】：

在Evert's answer 之上构建，DELETE 方法适合您的需求，只要您有代表两个用户之间关系的资源。

DELETE 方法的语义在RFC 7231 中定义：

4.3.5. DELETE

DELETE 方法请求源服务器删除目标资源与其当前功能之间的关联。 [...]

DELETE 方法实际上是幂等的，但是当将幂等性与状态码相关联时，您的引用根本上是错误的。

正如我之前在answer 中提到的，幂等性与状态码本身无关。幂等性是关于服务器上资源状态产生的效果，即使后续请求的响应与第一个请求不同。

假设客户端执行DELETE 请求以从服务器中删除资源。服务器处理请求，资源被删除，服务器返回204。然后客户端重复相同的DELETE请求，由于资源已经被删除，服务器返回404，这完全没问题。

尽管客户端收到的状态码不同，但单个DELETE请求产生的效果与多个DELETE对同一个URI请求的效果相同。