there you go. That's as simple as its gets, TSTTCPW. Way less cruft than Atom or RSS. It even says its simple - the Simple Object Access Protocol. REST is not that simple; you can fit the basics into a few slides, but
it's purpose is to induce simplicity into the right places, not be simple.
No, the issue isn't relative simplicity; it's how complexity is organised. Talking about something being simple when not actually looking at how inevitible complexity is going to be dealt with, is asking to get into the weeds. Tesler's Law is very real. REST is an architectural style described in architectural style talk - talk of principled design, constraints, derivation, quality properties. It's the kind of language you expect from cathedral enterprise architect types and IEEE diehards whose idea of a program manager is probably Gene Kranz. The kind of people Spolsky called astronauts; surely not for desperate Perl/Python/PHP hackers and smart people getting things done on the Web. REST like any architectural style is very much about managing the complexity that won't go away. It's a massive irony that system like the Web, but oftent frowned upon by architects, is so well articulated in its architecture, whereas the WS-* and previous EAI technologies that are used by architects have precious little to say about their overall effect. The important thing about REST is not that it's better or worse than SOAP/WS-* - the important is that REST is architecture turned up to 11, done right, not like the self-indulgence that neccesitated Agile.
So here's the thing for me - REST works. It does what it says on the tin, which is describe an approach to building a class of systems. It can be reasoned about. You can predict what might happen if you relax one constraint or introduce another. That process of taking away and adding to, is about as close to engineering as you can get in our industry (with the exception of continuous testing). Having REST was enormously when useful I worked on the Atom Protocol, and probably even more so on the Atom format (feeds are a kind of iterator, whereas the web is kind of decentralised hashtable; these are very different and a design tension results, that you wouldn't see with XMPP where feeds aren't needed). When it comes to designing APIs, having a well understood canon to 'spike' protocol designs against is FTW. I've found REST, and the approach it uses to define architecture, valuable, again and again since I came across the thesis. Want to take away uniformity? Put state in a particular place? Have servers invoke clients? Introduce write-thru cache? Sessions? Ok, we can reason about how that might work out or what the cost/benefits might be. I've never seen anything like that for WS-* or most middleware tech - it's all voodoo and sacrifice by comparison. You use a canon like REST the way building architects and masons once used De architectura.
There is a hype cycle around REST, which will be a problem for a while and then it will go away as hype cycles do. In the meantime the REST canon won't be rewritten to suit 65 day business cycles or strategic vendor concerns. I think somtimes that the problem people have with REST is that it's so well-defined; it's not witchcraft, it's not a cargo cult. You can't argue with it on a relativistic basis or apply clever rhetoric or continously redefine what it means. An architectural styles isn't "good" or "bad" - you have to decide if it's the right fit for your problem space and if not, you have to come up with a more appropriate one.
I linked to "Beyond REST? Building data services with XMPP" recently, where REST is described as non-Newtonian physics. Which is an excellent line, but if we are going to say that, and say there is something up with constraints when we need to hit a server on average 500 times to get an interesting event, we eventually have to show up with another physics. That's how an engineering science should work. One that offers explanation and predictability. XMPP I think is a great protocol, but it is not that. Happily there is a candidate - Rohit Khare's Extending the REpresentational State Transfer (REST) Architectural Style for Decentralized Systems. This will be important reading for people who are hitting a scale wall on the client server constraint of REST (as found on the Web), now or the next few years.
Previous Topic
