[gleb]

Caching is a poor argument for REST, as is it's provably false.

Experience has shown that you cannot make a useful HTTP cache without replicating some custom per-app business logic into it. Paul's example below is a simple case where you HTTP cache would need to support triggers to invalidate one "resource" when another one is updated.

Worse yet, you only get one set of cache headers in your response, and you really need two, one to control the reverse proxy and one for the browser. So any reasonable reverse proxy will (configurably) ignore all caching instructions in the headers.

In general the whole multi-tiered cache framework envisioned in rfc 2616 was a failure. It's just not powerful enough to do anything useful, and it gets in the way.