Cal*_*leb 54 rest http undelete http-delete
支持数据服务的取消删除或延迟/批量删除是一个相当普遍的要求.我想知道的是如何以RESTful方式实现它.我在几个不同的选择之间徘徊(其中没有一个对我来说似乎非常有吸引力).我认为,这些不同选项的共同点是需要一个API,它返回标记为特定资源类型的已删除的所有资源.
以下是我考虑过的一些选项以及它们的一些优点/缺点:
将资源标记为已删除的选项:
GET-ing资源标记为删除时的选项:
包含此已删除资源的响应选项:
更新标记为删除的资源时的选项:
取消删除标记为删除的资源的选项:
这绝不是一份详尽的清单.我只是想列举一些在我脑海中蹦蹦跳跳的选项.
我知道如何做到这一点的答案就像往常一样,"它取决于".我很好奇的是你会用什么资格/要求做出决定？您是如何看待自己实施或实施的？
通过这本书:RFC 2616-9.7:
The DELETE method requests that the origin server delete the resource
identified by the Request-URI. This method MAY be overridden by human
intervention (or other means) on the origin server. The client cannot
be guaranteed that the operation has been carried out, even if the
status code returned from the origin server indicates that the action
has been completed successfully. However, the server SHOULD NOT
indicate success unless, at the time the response is given, if it intends
to delete the resource or move it to an inaccessible location.
删除资源时,服务器应标记要删除的资源.它实际上不必删除资源,它只是不能保证已经执行了操作.即便如此,服务器也不应该说它已经被删除了.
A successful response SHOULD be 200 (OK) if the response includes an entity
describing the status, 202 (Accepted) if the action has not yet been enacted,
or 204 (No Content) if the action has been enacted but the response does not
include an entity.
如果操作被延迟,则发送202和描述操作结果的实体主体.(想想一个表示服务器延迟删除资源的可轮询的"任务";理论上它可以永远保留在该状态.)它所要做的只是阻止客户端以原始形式再次检索它.使用410作为响应代码,当"任务"完成或服务器以其他方式删除资源时,返回404.
但是,如果DELETE的语义对于有问题的资源没有意义,可能它不是您正在寻找的删除,而是一个添加状态转换,它改变资源状态但保持可访问性？在这种情况下,使用PUT/PATCH更新资源并完成.
“删除”（废弃）的项目也可以被视为资源，对吧？然后我们可以通过以下方式之一访问该资源（例如，对于已删除的用户）：
PATCH deleted_users/{id}
PATCH trash/users/{id}
PATCH deleted/users/{id}
或者有些人可能认为这是更放松的方式：
PATCH deleted/{id}?type=users
在有效负载中是这样的：
{ deleted_at: null }
我认为解决这个问题最 RESTful 的方法是使用 HTTP PUT 将资源标记为删除（和取消删除），然后使用 HTTP DELETE 永久删除资源。要获取标记为删除的资源列表，我将在 HTTP GET 请求中使用一个参数，例如。?state=markedForDeletion. 如果您请求一个没有参数标记为删除的资源，我认为您应该返回“404 Not Found”状态。
简短版本
您不能使用原始 URI 上的任何方法对资源进行 REST 完全取消删除 - 这是不合逻辑的，因为对已删除资源尝试的任何操作都应返回 404 或 410。虽然这在规范中没有明确说明，但强烈暗示在 DELETE 方法1的定义中（强调）：
实际上，这种方法类似于 UNIX 中的 rm 命令：它表示对源服务器的 URI 映射的删除操作，而不是期望删除之前关联的信息。
换句话说，当您删除资源时，服务器不再将该 URI 映射到该数据。因此，您不能通过 PUT 或 POST 对其进行更新，例如“将其标记为未删除”等（请记住，资源被定义为 URI 和某些基础数据之间的映射）。
一些解决方案
因为它明确声明底层数据不一定被删除，所以它不排除服务器制作新的URI 映射作为 DELETE 实现的一部分，从而有效地制作可以稍后恢复的备份副本。
您可以拥有一个包含所有已删除项目的“/deleted/”集合 - 但您将如何实际执行取消删除操作？也许最简单的 RESTful 方法是让客户端使用 GET 检索项目，然后将其发布到所需的 URL。
如果您需要能够将已删除的项目恢复到其原始位置怎么办？如果您使用支持它的媒体类型，则可以在对来自 /deleted/ 集合的 GET 的响应中包含原始 URI。然后客户端可以使用它来 POST。这样的响应在 JSON 中可能如下所示：
{
"original-url":"/some/place/this/was/deleted/from",
"body":<base64 encoded body>
}
然后，客户端可以将该正文 POST 到该 URI 以执行取消删除。
或者，如果您的资源定义允许移动的概念（通过更新“位置”属性或类似的东西），那么您可以进行部分更新并避免整个对象的往返。或者，做大多数人做的事情并实现类似 RPC 的操作来告诉服务器移动资源！UnRESTful，是的，但在大多数情况下它可能会正常工作。
你如何决定这些事情
关于如何决定这些事情的问题：您必须考虑删除在您的应用程序上下文中的含义，以及您为什么需要它。在许多应用程序中，没有任何东西会被删除，“删除”实际上只是意味着“从所有进一步的查询/列表等中排除此项目，除非我明确取消删除它”。所以，它实际上只是一个元数据，或者一个移动操作。在这种情况下，为什么还要使用 HTTP DELETE 呢？一个原因可能是，如果您想要一个 2 层删除 - 一个可撤消的软或临时版本，以及一个硬/永久版本，嗯......不是。
如果没有任何特定的应用程序上下文，我倾向于像这样实现它们：
为方便起见，我不想再看到此资源：发布部分更新以将资源标记为“临时删除”
我不希望任何人能够再访问此资源，因为它令人尴尬/有罪/花钱/等：HTTP DELETE
下一个要考虑的问题是：永久删除是否应该只永久取消 URI 的映射，以便没有人可以再链接到它，或者是否也有必要清除底层数据？显然，如果您保留数据，那么管理员甚至可以恢复“永久”删除的资源（但不是通过任何 RESTful 接口）。这样做的缺点是，如果数据的所有者真的想要清除它，那么管理员必须在 REST 界面之外执行此操作。
我也遇到了这个问题，我一直在互联网上寻找最好的解决方案。由于我能找到的主要答案对我来说似乎都不正确，因此这是我自己的研究结果。
其他人是对的，这才DELETE是正确的出路。您可以包含一个标志来确定它是立即永久的DELETE还是移至垃圾桶（并且可能只有管理员才能执行立即永久的操作DELETE。）
DELETE /api/1/book/33
DELETE /api/1/book/33?permanent
然后后端可以将该书标记为已删除。假设您有一个 SQL 数据库，它可能是这样的：
UPDATE books SET status = 'deleted' WHERE book_id = 33;
正如其他人提到的，一旦DELETE完成，GET集合中的 a 就不会返回该项目。就 SQL 而言，这意味着您必须确保不返回状态为 的项目deleted。
SELECT * FROM books WHERE status <> 'deleted';
另外，当您执行 a 时GET /api/1/book/33，您必须返回 404 或 410。 410 的一个问题是它意味着永远消失（至少这是我对该错误代码的理解），因此只要该项目存在，我就会返回 404 ，但'deleted'一旦永久删除，标记为410。
注意：如果您想将数据保留 X 时间，然后在 CRON 作业中将其永久删除，请使用“deleted_on”字段来包含非永久删除发生的数据。然后上面的 SQL commabd 更改为类似... WHERE deleted_on IS NULL.
现在要取消删除，正确的方法是PATCH。PUT与用于更新现有项目的a 相反， thePATCH预计是对现有项目的操作。据我所知，该操作预计在有效负载中进行。为了使其发挥作用，需要以某种方式访问资源。正如其他人所建议的，您可以提供一个trashcan区域，该区域将在删除后显示该书。像这样的东西可以列出放入垃圾桶的书籍：
GET /api/1/trashcan/books
[{"path":"/api/1/trashcan/books/33"}]
因此，结果列表现在将包括书号 33，然后您可以PATCH通过以下操作进行操作：
PATCH /api/1/trashcan/books/33
{
"operation": "undelete"
}
如果您想让操作更加通用，您可以使用以下内容：
PATCH /api/1/trashcan/books/33
{
"operation": "move",
"new-path": "/api/1/books/33"
}
然后，“移动”可用于界面中任何可能的 URL 的其他更改。（我正在开发一个 CMS，其中页面的路径位于一个名为 的表中tree，每个页面位于另一个名为 的表中page，并且有一个标识符。我可以通过在表中的路径之间移动页面来更改页面的路径tree！这这就是 aPATCH非常有用的地方。）
不幸的是，RFC 没有明确定义PATCH，只是将其与如上所示的操作一起使用，而不是PUT接受表示目标项目的新版本（可能是部分版本）的有效负载：
PUT /api/1/books/33
{
"title": "New Title Here"
}
而相应的PATCH（如果您同时支持两者）将是：
PATCH /api/1/books/33
{
"operation": "replace",
"field": "title",
"value": "New Title Here"
}
我认为支持这么多的PATCH操作是疯狂的。但我认为一些很好的例子可以更好地理解为什么PATCH是正确的解决方案。
您可以将其视为：使用补丁是更改虚拟字段或运行复杂的操作，例如移动，否则需要GET, POST, DELETE（假设是DELETE立即的，您可能会收到错误并最终得到部分移动...) 在某种程度上，这PATCH类似于拥有任意数量的方法。orUNDELETE方法MOVE将以类似的方式工作，但 RFC 明确表示有一组标准化方法，您当然应该坚持使用它们，并且为PATCH您提供了足够的空间，而不必添加自己的方法。虽然我没有在规范中看到任何内容说你不应该添加自己的方法。不过，如果您这样做，请务必清楚地记录下来。