16

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

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

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

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

什么是干净的 REST 方法?

a)是否发布到/refreshes/新的“刷新请求”?

b) 是 PUT(带有空白文档)http://ip/someResources吗?

c) 别的?

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

4

2 回答 2

5

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

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

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

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


更好的方法

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


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

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

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

克里斯

于 2010-09-30T08:23:33.197 回答
2

HTTP 缓存似乎允许这样做。 http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.1.6

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

于 2010-09-29T13:11:22.150 回答