URI 不透明度和缓存公理答案

【问题标题】：Axiom of URI Opacity and CachingURI 不透明度和缓存公理
【发布时间】：2010-12-12 19:18:52
【问题描述】：

我很好奇其他开发人员如何在 Web 缓存的上下文中协调 http://www.w3.org/DesignIssues/Axioms.html#opaque。我更喜欢 Rails 基于我想要的格式（即 .json 或 .xml）为资源请求添加后缀的方法，而不是依赖于接受头，尽管它不是 URI 不透明的。

同样的问题也出现在 XHR 中。如果不添加查询参数以将其与标准 HTTP 请求区分开来，则必须禁用缓存。

我个人认为，对 URI 不透明度的最纯粹解释可能比实际更学术。意见？

【问题讨论】：

网址不透明度不是学术性的；它可以防止第三方对您的 URL 做出过多的假设。如果他们这样做了，您最终将不得不向后弯腰，以确保您的 URL 符合 Google、Yahoo、各种代理缓存、各种浏览器等的做法。

标签： http caching http-headers web-standards

【解决方案1】：

URI 的格式与可缓存性无关，只是需要注意带有查询参数的请求默认情况下是不可缓存的。关于 GET 请求的可缓存性的一切都由服务器响应上的 Cache-Control、Expires 和 Last-Modified（用于启发式缓存）标头驱动，而这些与资源是动态的还是静态的没有任何关系生成（或者更确切地说，您的浏览器不在乎，也无法区分）。

URL 不透明性旨在促进 REST 的主要原则之一，即服务应该是超媒体驱动的，而且实际上，客户端应该只“知道”一些众所周知的入口点 URL，并可以访问其他任何地方通过导航链接和表单（或其 API 等效项）。

【讨论】：

同意——我看到的问题是不可能使响应不同接受标头（即 HTML、XML、JSON）的 URI 可缓存，因为 URI 在所有情况下都是相同的。
实际上，并非如此：您可以在服务器响应上设置“Vary: Accept”，从而创建多个缓存“变体”的概念。这实际上让您可以为同一个 URI 拥有多个缓存条目，并将正确的条目提供给正确的客户端（在这种情况下，基于客户端的 Accept 标头）。