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

时间：2010-09-29 12:34:22

标签： http api rest api-design

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

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

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

干净的REST方式是什么？

a）是否要向/refreshes/发送新的“刷新请求”？

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

c）还有别的吗？

我喜欢（a）因为它会给我们一个识别＆amp;跟踪刷新命令，但担心我们创建了太多资源。有什么建议吗？

答案 0 :(得分：5)

我会选择'刷新'资源方法。这有两个主要好处

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

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

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

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

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

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

客户端也可以指定它将接受过时的响应，最多可达到一些最大的过期量。这会松开对缓存的约束，因此可能违反原始服务器对语义透明性的指定约束，但可能需要支持断开连接的操作，或者在连接不良时面临高可用性。

克里斯

答案 1 :(得分：1)

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