问REST缓存机制

EN

对于REST服务，您通常希望使用web和HTTP协议的可用缓存机制。这意味着在响应中使用缓存指令或实体标签。

在这种情况下，您要做的是完全消除对某些资源的某些请求，或者在收到请求后限制服务器需要完成的工作。

您需要分析您的应用程序，并且：

• 决定在客户端缓存资源的安全时间。如果某些东西可以安全地缓存几天，那么您在回复中会这样说。如果客户机再次使用相同的资源，它将不会向服务器发出请求，因为它已经缓存了它。
• 如果某些资源不能安全地缓存在客户端，那么您可以在服务器上缓存。这就是ETags进来的地方。客户问：“嘿，服务器，我有这个版本，还好吗？”然后服务器说它很好，否则就会给你最新的数据。新的数据现在有了另一个ETag，您可以重复这个过程。

您应该在网上搜索诸如"REST缓存策略“之类的内容，并查看其他更适合您的情况。

当然，现在缓存并不是单独发生的。你需要实现它。这意味着：

• 在服务器端，您需要添加缓存指令和实体标记，并将此机制与位于DB前面的实际缓存一起实现(框架通常在某种程度上支持这样的东西--因此它们可能会使您成为其中的一部分)。
• 您需要确保缓存不会干扰服务数据的一致性；
• 客户需要表现得很好。如果您将所有这些缓存都放在适当的位置，而客户端决定完全忽略它，那么您的工作几乎是徒劳无功的。这通常是通过“强迫”客户端发挥良好和拒绝任何不包括必要的头部为您获得“缓存命中”的请求。如果您已经有客户端不进行缓存，并且需要确保它们不刹车，那么这可能更难做到。

通常，这将在Controller和DB之间的一个层中处理(通常是实现Repository模式的层)。在这个存储层中，您将有处理缓存操作的代码。

一个简单的实现可能只是保留了先前请求的列表以及响应的内容；如果一个新的请求与前面请求的内容匹配，那么您将返回相同的响应(而不按DB获取它)。

然后，您将开始改进该实现--可能通过跟踪最后一次从DB获取缓存响应的时间，并决定如果上次缓存的响应比某个时间长一些，则重新捕获它。

您还可以拆分其他缓存失效策略，并对不同的实体使用不同的策略(一些实体可能永远不需要缓存，另一些实体可能根据请求的次数而不是时间而可以缓存，还有一些实体可能需要在与该ID匹配的实体发生写入事件时使其缓存失效.也可能是该类型实体的任何写事件)。

这里的基本内容是，您希望将逻辑从Controller中分离出来，并在理想情况下将其与实际查询数据库的代码分开。