如何处理 REST 中的陈旧数据？答案

【问题标题】：How to handle stale data in REST?如何处理 REST 中的陈旧数据？
【发布时间】：2012-05-31 00:29:03
【问题描述】：

例如，如果我调用 GET 来获取一个项目，用 DELETE 删除它并再次 GET，那么第二个 GET 应该如何工作？

我的意思是，通过正确遵循 REST 原则，既然 GET 可以被缓存，那么正确的方法是什么？在 REST 中处理陈旧数据的方法是什么？

【问题讨论】：

如果您刚刚删除了该项目，为什么还要尝试再次“获取”它？它不会存在。也许我遗漏了什么或者问题不清楚。
@Brent Pabst：考虑例如 UI 应用程序中的链接，其中删除发生在弹出窗口中，但 GET 链接在打开页面中并且没有得到更新，或者通过邮件传输并且用户将它们插入浏览器地址栏直接在删除等之间。这个要缓存！这个想法是，如果该项目不再存在，GET 应该如何工作。禁用所有缓存？有一些缓存可以接受吗？所有这些的 REST 方法是什么？
第二个 GET 自然会返回 HTTP 代码 404 Not Found。缓存是另一回事，我将提供一个非常不透明的答案：“它取决于”。但是如果有有第二个GET，它似乎很明显会产生404？
Chris 的评论应该是问题的答案，它绝对是 404，该死的缓存。无论如何，DELETE 都应该从缓存中清除该资源的密钥。

【解决方案1】：

如最初所述，DELETE 之后的 GET 应该产生 HTTP 404 错误，而与可能存在的缓存无关。逻辑代码应该足够聪明，可以从持久存储以及内存存储或缓存中删除记录。此外，UI 应该能够使用您认为合适的任何流程或过程来处理 404 的结果。

【讨论】：

【解决方案2】：

首先，行为取决于 DELETE 调用作为其响应代码返回的内容。

如果 DELETE 返回 200 - OK 或 204 - No Content，则客户端应在下次调用 GET 时获得 404 - Not Found。那是因为 202 和 204 表示资源被立即删除。

但是，如果 DELETE 返回202 - Accepted，则客户端有可能在之后的一段时间内成功获取资源。那是因为 202 表示该资源已被标记为删除，但不一定立即清理。

其次，如果涉及缓存，则应构建行为以与不存在缓存时发生的情况保持一致。成功的 DELETE 应始终导致从数据的真实来源以及任何缓存副本中删除。

【讨论】：