Doesn't including tokens like @me in a REST URI break HTTP caching?

Question

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?

Answer 1

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.