支持数据服务的取消删除或延迟/批量删除是一个相当普遍的要求.我想知道的是如何以RESTful方式实现它.我在几个不同的选择之间徘徊(其中没有一个对我来说似乎非常有吸引力).我认为,这些不同选项的共同点是需要一个API,它返回标记为特定资源类型的已删除的所有资源.
以下是我考虑过的一些选项以及它们的一些优点/缺点:
将资源标记为已删除的选项:
- 使用HTTP DELETE将资源标记为已删除.
- 使用HTTP PUT/POST更新已删除的标志.这感觉不对,因为它将基本上是删除的内容从HTTP DELETE方法映射到其他HTTP方法.
GET-ing资源标记为删除时的选项:
- 返回标记为已删除的资源的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路径专用于取消删除标记为删除的资源.
这绝不是一份详尽的清单.我只是想列举一些在我脑海中蹦蹦跳跳的选项.
我知道如何做到这一点的答案就像往常一样,"它取决于".我很好奇的是你会用什么资格/要求做出决定？您是如何看待自己实施或实施的？