我们在REST服务器上有一些资源，如下所示：
/someResources/foo /someResources/bar /someResources/baz 其中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)
HTTP缓存似乎允许这样做。 http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.1.6
设置标头max-age = 0，这将指示服务器客户端需要新版本。这样你就可以继续使用GET。