On REST

Some random thoughts — in a new post, since I found it strange to argue for REST in one comment thread and against it in another one :-)

Whatever you think about REST, there’s one thing you’ll have to give to the REST folks: They know what they are talking about, and they have very clear guidelines about what is RESTful and what is not. Even if you assume that there are far more SOAP advocates then RESTafarians (an assumption that’s not at all obvious), this doesn’t explain the difference in the number of disagreements within the respective communities. RESTafarians usually pretty quickly come to the same conclusions when they’re asked to assess the RESTfulness of some example.

The situation is totally different within the so-called SOA community. With the lack of a clear definition, it’s very easy to call anything “SOA” just to ride the wave. Some say that CORBA, DCOM and DCE-RPC are all instances of an SOA; some believe a registry is a central component, others don’t seem too sure (at least not if it’s based on UDDI).

So where do I stand? I truly like REST. I don’t buy some of the arguments, like e.g. the additional scalability you are supposed to get from sticking to a uniform interface. (I like a uniform interface, BTW, and I disagree, at least in some respects, with the ProcessMessage approach — I think you should at least distinguish between operations with side-effects and those without.) I’m also not a big fan of HTTP — the most important instance of REST — e.g. because of the ugly GET syntax. Still, you cannot argue that it simply works (something the SOA stuff still has to prove). I’m also a big fan of SOAP, hate XML-RPC, believe that documents/messages should be the central element and the starting point in an SOA design, think that metadata is hugely important and UDDI basically sucks, and somehow can’t help believing that we’ll end up with something resembling REST, but built on top of SOAP/WS-* and with mappings to different transport/transfer protocols.