RESTful 取消删除

Question

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

以下是我考虑过的一些选项及其优缺点:

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

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

获取标记为删除的资源时的选项:

• 为标记为已删除的资源返回 HTTP 状态 404。干净透明，但我们如何区分真正删除的资源与刚刚标记为已删除的资源。
• 返回 HTTP 状态 410。提供区分差异的方法，但 410 在技术上表示“应被视为永久状态。具有链接编辑功能的客户端应该在用户批准后删除对 Request-URI 的引用。”这里的“预期”和“应该”等词可能有足够的回旋余地。不确定 410 在客户中的支持/理解程度如何。
• 返回 HTTP 状态 200 并包含指示资源已删除的标志字段。这看起来很奇怪，因为首先删除它的想法是因为您实际上希望它不出现。这将过滤已删除资源的责任推给了客户。

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

• 省略标记为已删除的资源。干净简单。但是，如果您真的想了解已删除的资源怎么办。
• 将它们与指示它们已被删除的字段一起包括在内。这将过滤掉已删除资源的责任推给了客户端。如果您只想对事件或已删除的资源进行分页，这会使分页变得棘手。

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

• 使用 HTTP 状态 404。资源没了，对吧？但是，您如何区分标记为已删除的资源和实际已删除的资源。 404 响应中的 HTTP 主体可以在此处消除歧义，但随后客户端需要解析/解释您的主体以消除歧义。也许响应头可能对这里有帮助？哪一个？自定义 header ？
• 将 HTTP 状态 409 与有关必须首先取消删除资源的消息一起使用。

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

• 使用 HTTP PUT/POST 更新资源操作并再次将其标记为事件状态。这仅在您没有为资源的 GET 操作返回 HTTP 404 时才有效，因为它不会对“未找到”(404) 的资源进行 PUT/POST。
• 使用 HTTP PUT/POST 进行资源创建操作。这里的问题是哪个数据优先？创建操作中发送的数据？或者正在恢复的数据？将它从任何其他会返回它的查询中过滤掉。然后，如果资源标识符指向标记为已删除的资源，则将创建资源的 HTTP PUT/POST 视为取消删除。
• 单独的 REST 路径专用于取消删除标记为删除的资源。

这绝不是一个详尽的 list 。我只是想列举一些一直在我脑海中浮现的选项。

我知道如何做到这一点的答案是，像往常一样，“视情况而定”。我很好奇的是，您会根据什么资格/要求做出决定？您如何看待这个实现或您自己实现的？

Answer 1

照章办事: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 来更新资源并完成。