相关疑难解决方法(0)

支持数据服务的取消删除或延迟/批量删除是一个相当普遍的要求.我想知道的是如何以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路径专用于取消删除标记为删除的资源.

这绝不是一份详尽的清单.我只是想列举一些在我脑海中蹦蹦跳跳的选项.

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

在REST中 - 可恢复的DELETE给出了关于如何在REST中建模状态变化的很好的介绍.基本上,如果您拥有具有字段状态的资源,则只需将该资源的新版本添加到更新状态字段.

在本主题中,我想扩展此模型.假设您有一个可以处于两种状态的资源:1和2.与引用帖子中描述的简单模型相比,有三个转换从状态1遍历到状态2,而不是仅仅一个.

我的问题是:你如何在REST中模拟状态转换？

我自己不能想出一个类似RPC的POST,它可能不是非常RESTian:

POST http://server/api/x
     target_state=2&transition=3

这通过使用转换3 将资源x从状态1 改变为状态2.