Rest内容协商和缓存

Question

我想知道缓存如何与基于内容协商的API一起工作。由于要获取XML或JSON中的资源，URI将是相同的，例如：

http://example.com/bikes/mountain

该服务基于接受类型标头返回JSON / XML。缓存有多聪明？

例如：

• 如果一个客户端请求此操作，则使用Accept类型返回XML。
• 响应由web服务器缓存1分钟。
• 第二个客户端使用接受类型请求相同的资源以返回JSON

​

缓存检查接受/内容类型吗？或者这会导致JSON请求者取回XML数据，因为服务器就是这样缓存的？我希望这是非常明显的事情，它已经被处理好了，否则，在URI中包含.xml / .json难道不是一个相当大的论据吗？

我想我的问题基本上是，我能在使用标准缓存技术的同时安全地使用内容协商吗？

Answer 1

Darrel是正确的，因为Vary标头告诉客户端哪个请求标头，它可以更改以获得资源的不同表示形式。

该值告诉客户端，它可以通过设置或更改Accept (在您的例子中是JSON或XML)以不同的文件格式请求表示。如果你使用接受语言的标题，你也可以得到一个不同的代表你的山地自行车的英文和法文。

这两个请求发送不同的值，因此应该始终单独缓存它们。

当您在value头中使用'*‘值时，这意味着响应不应该被缓存。

Answer 2

是。查看RFC 2616中不同标题的描述。

在我对变量头的简单理解中，缓存将使用变量头中命名的标头字段来唯一地标识缓存的表示。

Answer 3

正如其他人所提到的，应该在HTTP响应中使用Vary: Accept报头，以确保缓存注意到基于协商的内容类型的内容更改。这是因为浏览器不会为不同请求的内容类型提供(或不会使用)错误的缓存变体。

问题是，即使是在今天(2022年)，Chrome在其HTTP缓存缓存中，每个URL只有一个变体(Firefox似乎做了正确的事情)。如果您只请求一次Vary和一次JSON表示，并且正确地下载了一个新的表示，那么它们将基于报头进行检测，但它们将只缓存最后下载的表示。

如果您首先在URL上加载HTML，然后在同一个URL上加载经过内容协商的JSON数据(使用JavaScript、fetch等)，这可能是一个问题。然后在实践中，这两个请求都不会真正被缓存:下载JSON将删除缓存的HTML，下次用户加载页面时，缓存将使用JSON而不是HTML，因此必须再次下载HTML，从缓存中删除JSON。然后再下载一次。

因此，在我看来，这使得它需要在URL或类似的东西中包括.json。

关于HTTP表示变体的新标准正在进行中。也请参阅这个快速博客帖子。可悲的是，甚至使用了服务人员目前无法在Chrome中帮助您。