如何正确设计一个restful API来使缓存失效？

Question

我有一个应用程序需要来自Service2的数据,它将永远返回给定请求的相同答案,除非它的后备数据库被更新.数据库很少更新,让我们说每年两次.

我想设计一个解决方案,以便应用程序缓存来自Service2的答案,但是从外部提供一个功能,以便使Application的缓存无效.我想过从应用程序中暴露一个RESTful Web服务,但我对如何正确设计它感到困惑.

/application/cache/invalidate是一个非RESTful URL - 我正在考虑/application/cache/使用HTTP POST调用.但是,在我看来,对于正确的RESTful设计,当POST用于更新资源时,要更新的内容应该包含在请求的主体中.

设计"InvalidateCache"restful webservice的正确方法是什么？

Answer 1

考虑使用DELETE而不是POST和为url:

/application/cache/ 

在休息时,既PUT和DELETE被认为是indempotent行动.也就是说,它们可以使用相同的结果资源状态重复多次.在这种情况下,您的缓存是资源,多个DELETE将导致相同的状态,清除缓存.

您可以考虑在您的网址中添加一个描述符,以澄清您正在清除缓存的内容而不是删除缓存对象本身.就像是

/application/cache/contents

或许,但这取决于你.如果需要,走这条路线还可能让您有选择地从缓存中删除.

Answer 2

这可能不会直接回答您的问题，但您可能还想查看HTTP ETags，它非常适合在 RESTful 设计中缓存。

这个想法是应用程序将从 Service2 获取资源，这将返回资源以及 ETag 标头（它可以是最后修改的时间戳或哈希）。然后，应用程序将与 ETag 一起缓存该资源。

当应用程序需要再次使用资源时，它可以使用缓存中的 ETag 标头向 Service2 发送 HTTP GET。

• 如果Service2发现资源自第一次返回给Application后没有改变，则返回一个空响应，HTTP状态为304（未修改），表示Application可以使用缓存中的数据。
• 如果数据已更新，Service2 将返回带有新 ETag 标头（和 HTTP 状态 200）的新资源。

如果您不介意通过 HTTP GET 查看资源是否更改，并且 Service2 可以轻松确定资源是否已更改（无需加载），则此方法很有效。

优点是 Service2 不必使其客户端（应用程序）的缓存无效，这可能不是一个很好的做法（如果您有很多客户端，可能很难做到）。