24 3. BUILDING FOR SEARCH ENGINES: FOLLOWING REST
(who no longer has to serve quite so many copies). The one problem is that it does tend to mess up your download statistics a bit, but server operators can decide if they want to pay that price.
Similarly, servers can run caches. Instead of browsers visiting the server directly, they hit a server cache (technically known as a reverse proxy) that checks to see if it already has a copy of the page and, if so, serves it, but otherwise asks the real server for it. If you build your web app to follow REST, you can often make your site much, much faster just by sticking a nice server cache (like Polipo) in front of it. But, of course, if you do bad things like use session cookies and ignore the rules about GET and POST, the server cache will just screw everything up. (Notice that only GETs can be cached; you wouldn’t want to cache the result of something like adding a new blog post or the next blog post would never get added!)
GET and POST are, of course, part of the next piece of architecture, which Fielding calls “Uniform Interfaces.” Every web app works the same basic way: there are a series of URLs which you perform methods on. The methods sometimes change the state of the object and the server always returns the resulting “representation” of the object.
Thus, the name: Representational State Transfer (REST).
