URI 不透明和缓存公理
我很好奇其他开发人员如何协调 http://www.w3.org/DesignIssues/Axioms。 html#opaque 在网络缓存的上下文中。我更喜欢 Rails 的方法，即根据我想要的格式（即 .json 或 .xml）为资源请求添加后缀，而不是依赖于 Accept 标头，尽管它不是 URI 不透明的。
XHR 也出现了同样的问题。如果不添加查询参数来将其与标准 HTTP 请求区分开来，则必须禁用缓存。
我个人认为，对 URI 不透明性的最纯粹的解释可能更多的是学术性而非实用性。意见？
I am curious how other developers reconcile http://www.w3.org/DesignIssues/Axioms.html#opaque in the context of web caching. I prefer the Rails' approach of suffixing resource requests based on the format I want, i.e. .json or .xml, rather than relying on the accepts header, despite the fact that it is not URI-opaque.
The same issue rears its head with XHR's. Without the addition of a query param to differentiate it from standard HTTP Requests, caching must be disabled.
I have personally opted that the purest interpretation of URI Opacity may be more academic than practical. Opinions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
URI 的格式与可缓存性无关，除了注意带有查询参数的请求默认情况下不可缓存之外。有关 GET 请求可缓存性的所有内容均由服务器响应上的 Cache-Control、Expires 和 Last-Modified（用于启发式缓存）标头驱动，这些与资源是动态还是静态没有任何关系生成（或者更确切地说，您的浏览器不关心并且无法区分）。
URL 不透明旨在促进 REST 的主要原则之一，即服务应该是超媒体驱动的，并且实际上，客户端应该只“知道”一些众所周知的入口点 URL，并通过导航链接到达其他任何地方和表单（或其 API 等效项）。
The format of a URI has nothing to do with cacheability, other than noting that requests with query parameters are not cacheable by default. Everything about the cacheability of a GET request is driven by the Cache-Control, Expires, and Last-Modified (for heuristic caching) headers on the server response, and these don't have anything to do with whether the resource is dynamically or statically generated (or rather, your browser doesn't care and can't tell the difference).
URL opacity is meant to promote one of the primary principles of REST, which is that services should be hypermedia-driven, and that really, clients should only "know" a few well-known entry point URLs, and get everywhere else by navigating links and forms (or their API equivalents).