Question: What’s up with this SOA-vs.-REST thing?

Answer: That’s not an easy question. The reason is that “SOA” is not defined by any single source, so different people mean different things when they use the term. Things are a little different for REST, since it’s coined by a single person and defined in a single paper. To be fair, some people point out that there is often a lot of discussion of what is and what isn’t “RESTful” — I believe those disagreements are at a different level … but let’s just ignore this for now and get back to the original question.

When some people say “SOA”, they talk about an approach to managing, organizing and structuring IT systems in a large enterprise context. Instead of applications, services become the central concept; business and IT are aligned more closely; services are submitted to strong governance processes … whether or not you agree with any of these ideas, you can see that they’re pretty high-level and not concerned with any particular implementation approach. When defined this way, you could implement an SOA approach using CICS and COBOL on a mainframe, C++ and CORBA on Unix, Java/Java EE, .NET or whatever option you prefer. Web services, POX and REST (or rather: RESTful HTTP) are also implementation options from this perspective. At this level, SOA and REST can’t be compared — there at completely different levels of abstraction, and address different problems. Let’s call the level this definition of SOA addresses the business level.

Others view “SOA” much more technically. To them, SOA is the abstract architecture behind the Web services stack (SOAP, WSDL, WS-* etc.). There are service providers that expose services that are described with formal contracts; non-functional aspects are described via policies; there’s a registry that contains service descriptions and is used both at design time and run time; messages, containing documents as a payload, flow from consumers to providers and back … this technical description is not intended to be a definition, because until now there has been no agreement what such a definition could look like. But it’s pretty different from REST, because REST defines some pretty strict constraints — most importantly, a uniform interface, identifiable resources, and hypermedia. There is no similar agreement (a set of constraints) about SOA, which is often criticized by RESTafarians. We can call this level the technical level.

Things often become confusing when one side talks about SOA on the technical level and compares it to REST, pointing out differences and arguing about the respective strengths, and the other side is talking about business level SOA. It is absolutely meaningful to talk about the relative merits of technical level SOA and REST as implementation options for business level SOA.