我应该将 Cache-Control: no-cache 添加到我的 REST API 的 GET 端点吗？答案

【问题标题】：Should I add Cache-Control: no-cache to GET endpoints of my REST API?我应该将 Cache-Control: no-cache 添加到我的 REST API 的 GET 端点吗？
【发布时间】：2020-02-14 03:35:59
【问题描述】：

使用 POST/PUT 创建 REST API 时很简单。它们是非幂等的，因此默认情况下不会被浏览器缓存。

但是，在创建 GET 端点时，事情变得更加复杂。我担心浏览器（或特定浏览器）默认情况下会尝试缓存 GET 请求，而我最终会得到陈旧的数据。

这种对激进缓存的恐惧是真的吗？

我们以端点GET /articles/123/comments为例。

尽管此端点是 GET 端点，但每个请求都可以返回不同的内容，因为文章的 cmets 被提交。

这会被缓存吗？
会被特定攻击性浏览器缓存吗？

假设响应中没有与缓存相关的标头。

content-length: 2518
content-type: application/json
date: Thu, 17 Oct 2019 07:51:59 GMT
status: 200

避免 GET 请求过时数据的最佳做法是什么？

似乎有不同的策略来解决这个问题，但最好的方法是什么？

通过唯一的查询字符串缓存我的 GET 调用？

例如。 GET /articles/123/comments?nonce=12312310980923409
添加Cache-Control: no-cache（这会一直受到尊重吗？）
添加ETag: xyz_HASH_OF_MY_LIST_OF_COMMENTS?
添加Cache-Control: max-age=0（禁用缓存）
添加Cache-Control: max-age=60（以减少缓存的最大持续时间）
别担心，假设没有像 ETag, Last-Modified 这样的标头，任何浏览器都不会缓存 GET 请求？

【问题讨论】：

标签： http caching browser-cache offline-caching http-caching

【解决方案1】：

对于浏览器来说，GET 请求看起来是一样的，无论它们是通过 JavaScript 发送到您的 REST API 还是您在地址栏中输入 URL。

如果不设置缓存头会怎样？

规范允许浏览器为所欲为。

默认情况下，浏览器会缓存对 GET 请求的响应，并在持续时间内使用“最佳猜测”方法。

您应该始终明确设置缓存以获得一致的行为。

更多详情，请参阅

如何避免内容陈旧？

对此没有简单的答案。这取决于您的资源更改的频率。如果它从不改变，您可以将其缓存很长时间，例如博客文章。如果它有时会发生变化，您可以将其缓存更短的时间，例如新闻 API。如果它“总是”变化，则不应缓存它，例如社交媒体新闻提要、股票价格 API 等。

【讨论】：