46

我正在尝试构建一个 RESTful webapp，在其中我使用 GET、POST、PUT 和 DELETE。但我有一个关于在这个特定应用程序中使用 DELETE 的问题。

先说一点背景：

我的 webapp 管理的通用实体也在另一个系统中管理（并且，它总是创建）。所以在我的 webapp 中，每个实体都将使用唯一的键存储在数据库中。但是我们通过 URL 访问它们的方式是使用另一个系统的唯一密钥。

我想一个简单的例子就可以清楚地说明这一点。取网址/entity/1。这将显示其他系统中ID 为 1 的实体的信息，而不是我自己的系统。事实上，我系统中的 ID 将完全隐藏。1在我自己的系统中，将没有用于访问 ID 为的实体的 URL 方案。

好的，现在我们知道了我的 webapp 的结构，让我们回到删除这些实体。

将有一种方法可以在我的系统中“删除”实体，但我在它周围加上引号，因为它实际上不会从数据库中删除它们。相反，它会使用一个属性标记它们，以防止它在您转到 时出现/entity/1。

正因为如此，我觉得我应该使用PUT（这种方式'删除'将是幂等的），因为我从数据的角度来看，只是设置一个属性。

所以，问题是：RESTful 方法是否对数据有保真度（在这种情况下，我很清楚我正在PUT学习），或者应用程序中的数据表示（在这种情况下，我似乎正在DELETE学习）？

4

3 回答 3

75

你应该使用DELETE.

您打算对数据执行的操作称为“软删除”：您设置了一个标志并避免出现已标记的项目。这是您的 web 应用程序内部的，用户不必知道您正在软删除而不是删除或您想做的任何事情。这就是为什么你应该使用DELETE动词。

于 2013-04-05T16:42:11.433 回答
4

我认为没有明确的答案。我会依赖 1. 软删除、恢复和销毁操作是否是您的 api 的实际功能或 2. 软删除只是一种“偏执”的数据库工程模式。

  1. “软”删除对于 api 客户端是透明的，在这种情况下使用DELETE动词似乎是可行的方法

    一切都好像要一劳永逸地删除该项目，但工程师希望将其保留在数据库中的某个位置

  2. Api 客户端具有恢复或销毁软删除资源的能力，在这种情况下，软删除和恢复可以POST在不同的操作 url 上使用，例如/resource/:id/softdelete，销毁操作将是使用DELETE.

    另一种方法可能是使用DELETE不带查询参数的软删除，并添加?destroy=true到实际销毁。但是这种方法似乎不那么明确并且更容易出错。

于 2021-05-04T09:43:04.367 回答
-1

DELETE 方法在 HTTP 中具有非常特定的语义，不能被 REST API 的设计重载或拉伸。具体来说，API 不应通过将 DELETE 映射到较小的操作来扭曲 DELETE 的预期含义，从而使资源及其 URI 可供客户端使用。例如，如果 API 希望提供“软”删除或其他一些改变状态的交互，它应该使用特殊的控制器资源并指示其客户端使用 POST 而不是 DELETE 进行交互。

资料来源：Mark Massé 撰写的 Rest-API 设计规则书

建议：

POST: /entity/1/your-soft-delete-controller-name
于 2021-07-28T12:44:01.797 回答