支持数据服务的取消删除或延迟/批量删除是相当普遍的要求。我想知道的是如何以 RESTful 方式实现这一点。我在几个不同的选择之间左右为难(其中没有一个对我来说非常有吸引力)。我相信,这些不同选项的共同点是需要一个 API,它返回所有标记为已删除的特定资源类型的资源。
以下是我考虑过的一些选项以及它们的一些优点/缺点:
将资源标记为已删除的选项:
- 使用 HTTP DELETE 将资源标记为已删除。
- 使用 HTTP PUT/POST 更新已删除标志。这感觉不对,因为它将本质上是从 HTTP DELETE 方法中删除的内容映射到其他 HTTP 方法中。
获取标记为删除的资源时的选项:
- 为标记为已删除的资源返回 HTTP 状态 404。干净透明,但是我们如何区分真正删除的资源与刚刚标记为已删除的资源之间的区别。
- 返回 HTTP 状态 410。提供区分差异的方法,但 410 从技术上讲它“预计将被视为永久性的。具有链接编辑功能的客户端应该在用户批准后删除对 Request-URI 的引用。” 这里的“预期”和“应该”这两个词可能有足够的回旋余地。不确定客户端对 410 的支持/理解程度如何。
- 返回 HTTP 状态 200 并包含指示资源已删除的标志字段。这看起来很奇怪,因为首先删除它的想法是因为您实际上希望它不出现。这将过滤已删除资源的责任推给了客户端。
包含此已删除资源的响应选项:
- 省略标记为已删除的资源。干净简单。但是,如果您真的想了解已删除的资源怎么办。
- 包括它们以及表明它们已被删除的字段。这将过滤已删除资源的责任推给了客户端。如果您只想对活动或已删除的资源进行分页,则分页会变得很棘手。
更新标记为删除的资源时的选项:
- 使用 HTTP 状态 404。资源不见了对吗?但是,您如何区分标记为已删除的资源和实际已删除的资源。404 响应中的 HTTP 正文可以在这里消除歧义,但随后客户端需要解析/解释您的正文以消除歧义。也许响应标头在这里可能会有所帮助?哪一个?自定义标题?
- 将 HTTP 状态 409 与有关如何首先取消删除资源的消息一起使用。
取消删除标记为删除的资源的选项:
- 使用 HTTP PUT/POST 进行资源更新操作并再次将其标记为活动。这仅在您没有为资源的 GET 操作返回 HTTP 404 时才有效,因为它不会自 PUT/POST 到“未找到”(404) 的资源。
- 使用 HTTP PUT/POST 进行资源的创建操作。这里的问题是哪些数据优先?在创建操作中发送的数据?还是正在取消删除的数据?将它从任何其他可能返回它的查询中过滤出来。然后,如果资源标识符指向标记为已删除的资源,则将创建资源的 HTTP PUT/POST 视为取消删除。
- 单独的 REST 路径专用于取消删除标记为删除的资源。
这绝不是一份详尽的清单。我只是想列举一些一直在我脑海中蹦蹦跳跳的选项。
我知道如何做到这一点的答案是,像往常一样,“这取决于”。我很好奇的是你会用什么资格/要求来做出决定?你是如何看到这个实现或自己实现的?