RESTful取消删除 [英] RESTful undelete

问题描述

支持数据服务的取消删除或延迟/批量删除是一个相当普遍的要求。我想知道的是如何以RESTful方式实现它。我在几个不同的选项之间徘徊（其中没有一个对我来说似乎非常有吸引力）。我认为，这些不同选项的共同点是需要一个API，它返回标记为特定资源类型已删除的所有资源。

It is a fairly common requirement to support undeletes or delayed/batched deletions for data services. What I'm wondering is how to implement this in a RESTful way. I'm torn between a few different options (none of which seems terribly attractive to me). Common across these different options, I believe, is the need for an API which returns all resource marked as deleted for a particular resource type.

以下是我的一些选项考虑和他们的一些优点/缺点：

Here are some options I've thought about and some of their pros/cons:

将资源标记为已删除的选项：

Options to mark resource as deleted:

• 使用HTTP DELETE将资源标记为已删除。


• 使用HTTP PUT / POST更新已删除的标志。这感觉不对，因为它将基本上是删除的内容从HTTP DELETE方法映射到其他HTTP方法。

选项当GET-ing资源标记为删除时：

Options when GET-ing resource marked for deletion:

• 返回标记为已删除的资源的HTTP状态404。清洁&透明，但我们如何区分真正删除的资源与刚刚标记为已删除的资源之间的区别。


• 返回HTTP状态410.提供方法来区分，但410技术上表示它被认为是永久性的。具有链接编辑功能的客户端应该在用户批准后删除对Request-URI的引用。在这里，预期和应该这两个词可能有足够的摆动空间。不确定在客户端中支持/理解410的情况。


• 返回HTTP状态200并包括指示资源被删除的标志字段。这似乎很奇怪，因为首先删除它的想法是因为你实际上想要它不出现。这推动了将已删除资源过滤到客户端的责任。

包含此已删除资源的响应选项：

Options for responses which include this deleted resource:

• 忽略已删除的资源。清洁&简单。但是如果你真的想知道已删除的资源怎么办。


• 将它们与表示它们被删除的字段一起包括在内。这推动了将已删除资源过滤到客户端的责任。如果你只想浏览活动或已删除的资源，它会使分页变得棘手。

更新标记为删除的资源时的选项：

Options when updating a resource marked for deletion:

• 使用HTTP状态404.资源是否正确？但是，如何区分标记为已删除的资源与实际删除的资源之间的区别。 404响应中的HTTP正文可以在此消除歧义，但随后客户端将解析/解释您的正文以消除歧义。也许响应标题可能有帮助吗？哪一个？自定义标题？


• 使用HTTP状态409以及有关资源必须首先取消删除的消息。

取消删除标记为删除的资源的选项：

Options to undelete resource marked for deletion:

• 使用HTTP PUT / POST进行资源的更新操作并再次将其标记为活动。这只有在您没有为资源的GET操作返回HTTP 404时才有效，因为它自从PUT / POST到未找到（404）的资源后才会生成。（/ li>
  
• 使用HTTP PUT / POST进行资源的创建操作。这里的问题是哪些数据优先？在创建操作中发送的数据？或者正在取消删除的数据？将其从任何其他可能返回的查询中过滤掉。然后，如果资源标识符指向标记为已删除的资源，则将创建资源的HTTP PUT / POST视为取消删除。


• 单独的REST路径专用于取消删除标记为删除的资源。

这绝不是一份详尽的清单。我只是想列举一些在我脑子里蹦蹦跳跳的选项。

This is by no means an exhaustive list. I just wanted to enumerate some of the options that have been bouncing around in my head.

我知道如何做到这一点的答案就像往常一样，它取决于。我很好奇的是你会用什么资格/要求做出决定？您是如何看待这个实现或自己实现的？

I know the answer to how to do this is, as usual, "it depends". What I'm curious about is what qualifications/requirements would you use to make your decision? How have you seen this implemented or implemented it yourself?

推荐答案

读完这本书：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.

当您删除资源时，服务器应该标记要删除的资源。它实际上不必删除资源，它只是不能保证已经执行了操作。即便如此，服务器也不应该说它已经被删除了。

When you DELETE a resource the server should mark the resource for deletion on it's side. It doesn't really have to delete the resource, it just can't give any guarantee that the operation has been carried out. Even so, the server shouldn't say it's been deleted when it hasn't.

  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。

If the operation is delayed, send a 202 and an entity body describing the result of the action. (Think of a poll-able "task" representing the server's deferred deletion of the resource; It could theoretically leave it forever in that state.) All it has to do is prevent the client from retrieving it again in it's original form. Use a 410 for the response code, and when the "task" finishes or the server otherwise deletes the resource, return a 404.

但是，如果DELETE的语义对于有问题的资源没有意义，也许它不是你正在寻找的删除，而是一个改变资源状态但保持可访问的附加状态转换？在这种情况下，使用PUT / PATCH更新资源并完成。

However, if a DELETE's semantics don't make sense for the resource in question, perhaps it's not a deletion you're looking for, but an addition state transition that alters the resource state but keeps it accessible? In that case, use a PUT/PATCH to update the resource and be done.

这篇关于RESTful取消删除的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！