我正在尝试构建一个RESTful webapp，其中我使用GET，POST，PUT和DELETE。但我有一个关于在这个特定应用程序中使用DELETE的问题。
首先是背景：
我的webapp管理在另一个系统中也管理（并且，它发生，始终创建）的通用实体。因此，在我的webapp中，每个实体都将使用唯一键存储在数据库中。但我们通过URL访问它们的方式是使用其他系统的唯一键。
我认为，一个简单的例子可以说明这一点。获取网址/entity/1。这将显示其他系统中ID为1 的实体的信息，而不是我自己的系统。实际上，我系统中的ID将被完全隐藏。在我自己的系统中，没有用于访问ID为1的实体的URL方案。
好的，现在我们知道我的webapp是如何构建的，让我们回到删除这些实体。
我的系统中会有一种'删除'实体的方法，但我在它周围加上引号，因为它实际上不会从数据库中删除它们。相反，当您转到/entity/1时，它会使用一个属性来标记它们，以防止它出现。
因此，我觉得我应该使用PUT（以这种方式'删除'将是幂等的），因为从数据的角度来看，我只是设置一个属性。
所以，问题是：RESTful方法是否对数据具有保真度（在这种情况下很明显我是PUT ing），或者应用程序中数据的表示（在这种情况下似乎我是DELETE ing）？
答案 0 :(得分：44)
您应该使用DELETE。
您打算对数据执行的操作称为“软删除”：您设置一个标记并避免出现标记的项目。这是您的webapp内部的，用户不必知道您是软删除而不是删除或任何您想要做的事情。这就是你应该使用DELETE动词。
答案 1 :(得分：1)
我认为没有明确的答案。我将依赖于 1. 软删除、恢复和销毁操作是否是您的 api 的实际功能或 2. 软删除只是一种“偏执”的数据库工程模式。
“软”删除对于 api 客户端是透明的，在这种情况下，使用 DELETE 动词似乎是要走的路
一切都好像该项目将被一劳永逸地删除，但工程师希望将其保留在数据库中的某个位置
Api 客户端能够恢复或销毁软删除的资源，在这种情况下，软删除和恢复可以使用 PUT 或 PATCH（或 POST 在不同的action url like /resource/:id/softdelete) 并且销毁操作应该是使用 DELETE 的那个。
答案 2 :(得分：0)
DELETE 方法在 HTTP 中有非常具体的语义，不能重载 或由 REST API 的设计扩展。具体来说，API 不应扭曲预期的 通过将 DELETE 映射到离开资源的较小操作及其 URI 来确定 DELETE 的含义， 可供客户使用。例如，如果 API 希望提供“软”删除或某些 其他状态改变交互，它应该使用特殊的控制器资源和 指示其客户端使用 POST 而不是 DELETE 进行交互。
来源：Mark Massé 编写的 Rest-API 设计规则书
建议：
POST: /entity/1/your-soft-delete-controller-name