设计Restful API时，我应该对DEFOLLOW使用DELETE还是POST？

Question

我脑子里有一天这个问题，我试图从RESTful Web服务食谱和其他stackoverflow帖子中读到一些内容，但是仍然没有令人信服的答案：

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

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

因此，如果用户A想取消关注用户B，那么此API应该是DELETE还是POST？

在RESTful Web服务指南第11页中，它说：

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

这是否表明我们尽量避免使用DELETE？

感谢您对此问题有任何见识！

Answer 1

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

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

/api/userA/follows/userB

然后可以说该资源代表了两者之间的关系。它具有唯一的url，因此可以删除该url，我希望此时该关系将被切断。

Answer 2

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

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

4.3.5. DELETE

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

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

正如我之前在answer中提到的那样，幂等与状态码本身无关。幂等性是关于在服务器上的

资源状态

上产生的效果，即使后续请求的响应不同于第一个请求。考虑客户端执行DELETE请求以从服务器删除资源。服务器处理请求，资源被删除，服务器返回204。然后，客户端重复相同的DELETE请求，并且由于资源已被删除，服务器返回404，这完全可以。

尽管客户端接收到不同的状态代码，但由单个DELETE请求产生的

效果

与针对同一URI的多个DELETE请求的效果相同。