[paul]

If your application is a simple key/value store, then scaling won't be a problem. If it's something more complex, then such simplistic caching models won't work.

For example, the FriendFeed api includes a method that fetches multiple feeds at once: http://friendfeed.com/api/feed/user?nickname=paul,bret,jim&#... Where should one user PUT their updates such that a simple HTTP cache will know to invalidate that GET? It's not possible. The cache must understand the internals of the system in order to do proper invalidation here.

[gunderson]

not really, the system would only need to keep track of the last updated time of each record and when aggregating them, set the proper etag.

[paul]

Right, that means that you are doing your own cache invalidation (by changing the etag or last modified time), not relying on some magic proxy which watches for PUT and DELETE. That also means that you can use normal HTTP and ignore this REST nonsense.

[gunderson]

Fair enough, but the thing I like about REST is the consistent API and (ideally) proper handle of request types via mime type information in the header.