http - REST API 设计 : Tell the server to "refresh" a set of resources

Question

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

• /someResources/foo
• /someResources/bar
• /someResources/baz

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

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

什么是干净的 REST 方法？

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

b) 是否将(带有空白文档)PUT 到 http://ip/someResources ？

c) 还有别的吗？

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

Answer 1

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

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

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

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

更好的方法

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

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

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

客户端也可以指定它将接受陈旧的响应，直到达到某个最大的陈旧量。这放宽了对缓存的限制，因此可能会违反源服务器对语义透明性的指定限制，但可能有必要支持断开连接的操作，或在连接性差的情况下实现高可用性。

克里斯