使用浏览器缓存进行增量更新

客户端（AngularJS 应用程序）从服务器获取相当大的列表。列表可能有数百或数千个元素，这可能意味着未压缩的几兆字节（并且一些用户（管理员）获得更多数据）。

我不打算让客户端获得部分结果，因为排序和过滤不应该打扰服务器。

压缩效果很好（大约为 10）并且列表不会经常更改，304 NOT MODIFIED也有很大帮助。但缺少另一个重要的优化：

由于列表的典型更改相当小（例如，修改两个元素并添加一个新元素），因此传输更改听起来像是一个好主意。我想知道如何正确地做到这一点。

就像是GET /offer/123/items应该总是返回报价编号 123 中的所有商品，对吗？这里可以使用压缩和304，但不能进行增量更新。像这样的请求GET /offer/123/items?since=1495765733听起来像是可行的方法，但是浏览器缓存并没有被使用：

• 要么什么都没有改变并且答案是空的（并且缓存它没有意义）
• 或者某些内容发生了变化，客户端会更新其状态，并且自 1495765733 以来不再要求更改（并且缓存它更没有意义）

显然，当使用“since”查询时，不会为“资源”缓存任何内容（原始查询仅使用一次或根本不使用）。

所以我不能依赖浏览器缓存，只能使用localStorage or sessionStorage，它有一些缺点：

• 它限制为几兆字节（浏览器 HTTP 缓存可能更大并且会自动处理）
• 当我达到极限时，我必须实施一些替代策略
• 浏览器缓存存储了我没有得到的已经压缩的数据（我必须重新压缩它们）
• 它不适用于获得更大列表的用户（管理员），因为即使单个列表也可能已经超出限制
• 注销时它会被清空（客户的要求）

考虑到有 HTML 5 和 HTTP 2.0，这还不够令人满意。我缺少什么？

是否可以将浏览器 HTTP 缓存与增量更新一起使用？

我认为您缺少一件事：简而言之，标题。我认为你可以做的并且符合（大多数）你的要求的是：

• First GET /offer/123/items正常进行，没有什么特别的。
• 随后的GET /offer/123/items将与Fetched-At: 1495765733标头，指示您的服务器何时发送初始请求。

从现在开始，有两种可能的情况。

• 要么不做任何改变，发送304即可。
• 但是，如果有更改，则返回新项目，因为先前发送的时间戳具有标头，但设置Cache-Control: no-cache从你的回复来看。

这使您可以进行增量更新，并缓存初始兆字节大小的元素。

但仍然有一个缺点，即缓存仅执行一次，它不会缓存更新。你说你的列表不经常更新，所以它可能已经对你有用，但如果你真的想进一步推动这一点，我可以再想一件事。

收到增量更新后，您可以在后台触发另一个请求，而无需Fetched-At您的应用程序根本不会使用该标头，而只是用于更新您的 http 缓存。它不应该像听起来那么糟糕，因为您的框架不会使用新框架更新其数据（并可能触发重新渲染），唯一值得注意的缺点是网络和内存消耗。在移动设备上这可能会出现问题，但听起来并不像是一个打算在移动设备上显示的应用程序。

_{I absolutely don't know your use-case and will just throw that out there, but are you really sure that doing some sort of pagination won't work? Megabytes of data sounds a lot to display and process for normal humans ;)}