REST (for REpresentational State Transfer) is one of those acronyms that is thrown around in tech circles fairly often these days. I suspect, people bring it up as an antidote to SOAP and WS-* that are growing ever more complex, just like the LAMP (Linux, Apache, MySQL and Perl/Python/PHP) stack is somewhat of a rebellion against ever-more complex J2EE and .NET and so forth.

I had read probably at least a dozen explanations of what REST is supposed to be over the years, but they sounded to me like while there was clearly a good idea in there somewhere, it certainly wasn’t concise and crisp and simple and useful enough for me that I would consider it a "paradigm".

Until last night, that is, when I finally read the respective chapter in Roy Fielding‘s PhD thesis, which is of course the document that first described REST. You guys out there, explaining REST to the rest of the world, I have to tell you that Roy is doing a much better job than any of the secondary literature that I’ve read on the subject. Reading what he had to say, it actually made sense! And it is concise and crisp and simple and useful, so it’s indeed a paradigm to me! Not that anything I read ever was quite wrong; but somehow all of it missed the spark that’s woven through Roy’s description, in spite of the fact that it’s a PhD thesis where sparks aren’t quite the first thing that comes to mind when thinking about their presentation (yep, I’ve gone through that process, too).

So anybody who is trying to understand REST: read what Roy has to say, and forget everything else until you grokked what he said.

P.S. It also clearly shows REST’s limitations (which indicates how good the documentation is that Roy put together!). The load that RSS feeds put on everybody’s servers should be exhibit no. 1 for any zealot arguing that REST is for everything. Of course, few people do, but I wonder whether there’s a "REST+1" architecture somewhere to be thought of and described that only adds a few minimal extensions to it, and, say, solves the RSS load problem by allowing incremental updates, for example.