REST API 设计：告诉服务器“刷新”一组资源答案

【问题标题】：REST API design: Tell the server to "refresh" a set of resourcesREST API 设计：告诉服务器“刷新”一组资源
【发布时间】：2010-09-29 12:34:22
【问题描述】：

我们在 REST 服务器上有一些资源，结构如下：

其中someResource 是远处分布式对象的服务器表示。

我们想告诉服务器通过在网络中查看它并更新服务器的缓存来“刷新”它对该“分布式对象”的表示，即我们不能简单地 PUT 新值。

什么是干净的 REST 方法？

a) 是否向/refreshes/ 发布新的“刷新请求”？

b) 是否要 PUT（带有空白文档）到 http://ip/someResources ？

c) 别的东西？

我喜欢 (a)，因为它会给我们一个 id 来识别和跟踪刷新命令，但担心我们会创建太多资源。有什么建议吗？

【问题讨论】：

【解决方案1】：

我会采用“刷新”资源方法。这有两个主要好处

(a) 与生命周期操作（复制、克隆、移动）一样，刷新的目的与底层资源的功能正交，因此应该完全分开

(b) 它为您提供了一些检查刷新进度的方法 - 刷新资源的外部状态将为您提供“状态”或“进度”属性。

我们以这种方式实现了生命周期操作，关注点分离是一个很大的设计优势。

另一种管理方式是允许服务器在一段时间内缓存它的资源表示，只在超时后才真正检查真实状态。在此模型中，您的服务器实际上是一个中间缓存资源，应遵循 HTTP 缓存行为，请参阅here 了解更多详细信息。下面我引用了一个非常相关的部分，它讨论了客户端覆盖缓存值。

13.1.6 客户端控制的行为 虽然原始服务器（以及在较小程度上，中间缓存，由于它们对响应时间的贡献）是过期信息的主要来源，但在某些情况下，客户端可能需要控制缓存关于是否返回缓存的决定响应而不验证它。客户端使用 Cache-Control 标头的多个指令来执行此操作。

客户端的请求可以指定它愿意接受未经验证的响应的最大年龄；指定零值会强制缓存重新验证所有响应。 客户端还可以指定响应过期之前剩余的最短时间。这两个选项都增加了对缓存行为的约束，因此不能进一步放松缓存对语义透明度的近似。

客户端也可以指定它将接受陈旧的响应，直至达到某个最大陈旧量。这会放松对缓存的约束，因此可能会违反源服务器对语义透明性的指定约束，但对于支持断开连接的操作或面对连接性较差时的高可用性可能是必要的。

克里斯

【讨论】：

您能否详细说明 status/progress 属性？它会尝试返回刷新完成的百分比，还是返回一个指示刷新仍在进行中的标志？在这种情况下，对同一资源的重复请求会做什么？不确定我的问题是否清楚。我还没有实现这样的东西。
@Leonid 响应的性质可以是任何你想要的。对于长时间刷新，您可能希望在资源的结果中返回带有 URL 的 201（已接受）响应 - 该 URL 上的后续 GET 可以告诉刷新的状态。不过，也请查看我对这个问题的最新更新。

【解决方案2】：

设置标头 max-age=0，这将告诉服务器客户端需要一个新版本。这样您就可以继续使用 GET。

【讨论】：

谢谢 Darrel，如果刷新速度很快，HTTP 缓存会很好，但是……我应该解释一下刷新需要几分钟，因此有了 REST 资源的想法——“刷新”。我现在认为 /Refreshes/ 可以处理初始检索和将来的刷新操作，即它支持带有一组选项的 POST 刷新标识符（例如“1,2,5”意味着 1 和 2 需要“刷新”，5 到被检索，并且先前缓存的 3 被忽略）因此，如果标识符集为 null ...刷新所有当前缓存的表示。我认为这是有道理的？？？
我曾经做过类似的事情，我创建了一个名为 /RefreshRequests 的集合资源如果我在 /RefreshRequests 上执行 GET，我可以看到已启动的请求的历史记录。可以为单个请求分配一个 id，以便 GET /RefreshRequest/232 可以返回请求的当前状态。