2

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?

Chris Sears
  • 6,502
  • 5
  • 32
  • 35
  • FWIW I believe that most of these APIs also support "me" and "self" in addition to "@me" and "@self", or will at least start supporting those. The Google+ API accepts "me" at least. – Jason Hall Sep 20 '11 at 00:14

1 Answers1

2

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.

Darrel Miller
  • 139,164
  • 32
  • 194
  • 243
  • Perhaps part of their logic was that all new Google APIs now must use HTTPS, so public caching is already not possible. If they wanted to use a cache like Squid internally, perhaps they could do the token replacement on the external load balancer where the HTTPS session terminates, and then pass it on with the cache-friendly URL in place. – Chris Sears Sep 24 '11 at 19:52
  • @ChrisSears There is still local private caches to consider. WinInetcache will cache https resposnes and what happens if two people both use the same PC under the same windows account? – Darrel Miller Sep 24 '11 at 21:15