[paul]

Yeah, the comments are crazy and seem to completely miss the point.

HTTP is wonderful, but I've gotten along just fine without ever using PUT or DELETE or other bits of REST dogma, as has the rest of web. Sometimes my urls are actually verbs that I POST arguments to instead of "RESTful" nouns, and it works great.

[gunderson]

Right it may work for you, which is fine.

The point of REST that I thought really stood out in the comments was the one about caching.

If you know that any GET request can be cached subject to whatever is in the expires header or etag, that is hugely useful information when scaling.

REST is not a straight jacket, it's just a simple way of making the /site/url/you/use + the method mean something consistent and logical.

[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.

[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.