Hacker News new | ask | show | jobs
by gunderson 6511 days ago
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.
2 comments
paul 6511 days ago
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.

link
gunderson 6511 days ago
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.
link
paul 6511 days ago
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.
link
gunderson 6510 days ago
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.
link
gleb 6510 days ago
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.

link