8

我有一个关于 HTTP DELETE 和 REST 的问题。我有一个资源x。根据 x 的状态，删除x会：

  1. 永久删除x 。
  2. 将x标记为已删除。这意味着x可以在以后恢复。

我假设 HTTP DELETE必须根据 HTTP/REST 规范删除资源，而不是将其标记为已删除，例如：在处理 HTTP DELETE 后， x上的 GET必须返回 404。这意味着 HTTP DELETE 不能用于第二种情况。您将如何以 RESTful 方式对这种删除行为（1 和 2）建模？

然后，由于可以恢复某些资源，因此也应该通过 REST API 来实现。您将如何以 RESTful 方式对还原行为进行建模？

为简单起见，我们假设x位于http://company/api/x/上。

4

3 回答 3

5

你可以使用垃圾桶的方法。

DELETE http://company/api/x/

导致 x 被移动到垃圾箱。此时可以通过以下方式访问它，

GET http://company/api/trashcan/x/

如果你想恢复它，然后获取检索到的表示并执行

PUT http://company/api/x/

更新：

使用超媒体使客户更清楚他们应该做什么。

GET http://company/api/trashcan/x
=>
200 OK

<x-resource>
  <description>This is the object I deleted</description>
  <link rel="restoreto" href="http://company/api/x/" />
</x-resource>

再想一想，PUT 确实是正确的方法。它是不安全的、幂等的，而且您也知道恢复文件的 URI。如果完全符合 PUT 的语义。rel="restoreto" 的替代方法可能是 rel="originallocation"。

于 2011-07-20T14:56:28.497 回答
3

您的资源可以存在于多种状态（活动、标记为删除、已删除）中的任何一种状态，并具有将资源从一种状态移动到另一种状态的操作。这是状态机的经典定义。对于给定的转换，您会发现自己在问“什么 HTTP 动词代表该特定转换？我必须滥用一个吗？POST 是一个包罗万象的方法吗？我可以自己发明吗？” 有个更好的方法。直接暴露状态，使用 GET 和 PUT 进行修改。让服务器弄清楚如何从以前的状态到新的状态。例如，您可能有一个资源：

GET /foo -> {"a": 1, "b": 2, "status": "active"}

你想改变它，以便：

GET /foo -> {"a": 1, "b": 2, "status": "marked"}

您可能很想知道 DELETE 是否适合于此，或者某些自定义方法，或者您可以只是 PUT 那个新状态并完成：

GET /foo -> {"a": 1, "b": 2, "status": "active"}
PUT /foo <- {"a": 1, "b": 2, "status": "marked"}
GET /foo -> {"a": 1, "b": 2, "status": "marked"}
于 2011-07-20T15:22:28.790 回答
0

RESTful 意味着您可以使用 POST 来执行删除，因为：与基于 SOAP 的 Web 服务不同，RESTful Web 服务没有“官方”标准。

在这种情况下，我会将您的 Mark For Delete 更改为 POST（它实际上是更新而不是删除）。

于 2011-07-20T13:31:08.233 回答