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

Question

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

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

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

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

Answer 1

考虑使用DELETE代替POST和网址：

/application/cache/ 

在REST中，PUT和DELETE都被视为无效操作。也就是说，它们可以使用相同的结果资源状态重复多次。在这种情况下，您的缓存是资源，多个DELETE将导致相同的状态，清除缓存。

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

这样的东西

/application/cache/contents

或许，但这取决于你。如果有必要，也可以选择从缓存中删除该路由。

Answer 2

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

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

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

• 如果Service2在第一次返回Application时发现资源没有被更改，则返回一个空状态响应，其状态为304（未修改），表明Application可以使用缓存中的数据。
• 如果数据已更新，Service2将返回具有新ETag标头的新资源（并且HTTP状态为200）。

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

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