在 REST URI 中包含像 @me 这样的令牌不会破坏 HTTP 缓存吗？
opensocial和一些较新的Google API包括这些令牌，例如“ @me”或“@self”，其值由API服务器替换为基于当前身份验证的用户的值。例如，“/api/people/@me/@asl asl ass opensocial Rest URL”。
这是否会破坏REST API支持本机HTTP缓存服务器（如Squid）的目标？
即使您可以使用“变化”标头解决问题，这似乎是一个主要的缺点。而且，真正的好处是允许开发人员将某些URI对其应用进行核对。有人知道为什么它是这样设计的吗？
OpenSocial and some of the newer Google APIs include these tokens, such as "@me" or "@self", whose values are replaced by the API server with values based on the currently authenticated user. For example "/api/people/@me/@all" is an OpenSocial REST URL.
Doesn't this break with the goal of REST APIs to support native HTTP cache servers (like Squid)?
Even if you could get around the issue using the "Vary" header, it seems like a major drawback. And only real benefit is to allow developers to hard code some URIs into their apps. Anyone know why it was designed this way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，这将使公共缓存的使用变得困难。就我个人而言，我认为这是一个非常糟糕的主意，而且似乎确实是为了让客户端更容易构建 URI。我有时想知道像 memcached 这样的缓存服务器的广泛使用是否会导致开发人员忘记 http 缓存的好处。
Yes it will make the use of public caches difficult. Personally I think it is a really bad idea and does seem to be driven by the desire to make it easier for clients to construct URIs. I sometimes wonder if the extensive use of caching servers like memcached are causing developers to forget about the benefits of http caching.