Surviving Slashdot
I was able to survive a slashdotting yesterday. The solution was simple:
Redirect /wiki/pie/Rss20AndAtom10Compared http://www.tbray.org/atom/RSS-and-Atom
The key issue wasn’t so much load as it was trolls.
My ability to do so, and so easily, speaks volumes about the power of the REST architecture. Consider:
- I was able to effectively replace one service which conceptually supported one interface (an EditText link) with another service that supported a different interface.
- I was able to do all this efficiently and transparently, and
without the prior agreement of the end user, SlashDot, or Tim
Bray.
- Though in the latter case, I had previously talked to Tim about doing exactly this if trolls became an issue, and I did check with him as soon as the sun had traveled a bit further west and he had awoken. He indicated that Apache serving this data as a static file was not putting any appreciable load on his server, another benefit that I won’t explore further here.
- I was able to do this at a fine grain level, i.e. at the level of a single page. I did not need to redirect the entire wiki, nor did I need to modify or customize one line of code in the wiki software itself.
The foundation for most of this is rooted in the tantalizing phrase hypermedia as the engine of application state. If one views a wiki as a state machine, then being able to do a redirect is effectively changing the programming of the application.
The fact that I was able to do all this with but a single line of code — and using only the protocols and products that were already installed — was of great value to me yesterday. In fact, if one were predisposed to use such terms, I would go so far as to say it was of significant business value to me.
This is part of the reason for my continued skepticism when I hear claims that Indigo will be providing first class support for building REpresentational State Transfer (REST) web services.