SOAP vs REST: The war between simplicity and standards
SOA is, at its core, a design and development methodology. It embraces reuse through decomposition of business processes and functions into core services. It enables agility by wrapping services in an accessible interface that is decoupled from its implementation. It provides a standard mechanism for application integration that can be used internally or externally.
It is, as they say, what it is.
SOA is not necessarily SOAP, though until the recent rise of social networking and Web 2.0 there was little real competition against the rising standard. But of late the adoption of REST and its use on the web facing side of applications has begun to push around the incumbent.
We still aren't sure who swung first. We may never know, and at this point it's irrelevant: there's a war out there, as SOAP and REST duke it out for dominance of SOA.
At the core of the argument is this: SOAP is weighted down by the very standards designed to promote interoperability (WS-I), security (WS-Security), and reliability (WS-Reliability). REST is a lightweight compared to its competitor, with no standards at all. Simplicity is its siren call, and it's being heard even in the far corners of corporate data centers.
A February 2007 Evans Data survey found a 37% increase in those implementing or considering REST, with 25% considering REST-Based Web Services as a simpler alternative to SOAP-based services. And that was last year, before social networking really exploded and the integration of Web 2.0 sites via REST-based services took over the face of the Internet.
It was postulated then that WOA (Web Oriented Architecture) was the face of SOA (Service Oriented Architecture). That REST on the outside was the way to go, but SOAP on the inside was nearly sacrosanct.
Apparently that thought, while not wrong in theory, didn't take into account the fervor with which developers hold dear their beliefs regarding everything from language to operating system to architecture. The downturn in the economy hasn't helped, either, as REST certainly is easier and faster to implement, even with the plethora of development tools and environments available to carry all the complex WS-* standards that go along with SOAP like some sort of technology bellhop. Developers have turned to the standard-less option because it seems faster, cheaper, and easier. And honestly, we really don't like being told how to do things. I don't, and didn't, back in the day when the holy war was between structured and object-oriented programming.
While REST has its advantages, certainly, standard-less development can, in the long-run, be much more expensive to maintain and manage than standards-focused competing architectures. The argument that standards-based protocols and architectures is difficult because there's more investment required to learn the basics as well as associated standards is essentially a red herring. Without standards there is often just as much investment in learning data formats (are you using XML? JSON? CSV? Proprietary formats? WWW-URL encoded?) as there is in learning standards. Without standards there is necessarily more documentation required, which cuts into development time. Then there's testing. Functional and vulnerability testing which necessarily has to be customized because testing tools can't predict what format or protocol you might be using. And let's not forget the horror that is integration, and how proprietary application protocols made it a booming software industry replete with toolkits and libraries and third-party packages just to get two applications to play nice together. Conversely, standards that are confusing and complex lengthen the implementation cycle, but make integration and testing as well as long term maintenance much less painful and less costly.
Arguing simplicity versus standards is ridiculous in the war between REST and SOA because simplicity without standards is just as detrimental to the costs and manageability of an application as is standards without simplicity.
Related articles by Zemanta
Published Dec 05, 2008
Version 1.0
Lori_MacVittie
Employee
EmployeeLori_MacVittieEmployee
Employee
Lori_MacVittie@David,
They are, agreed, and they are also used by SOAP.
REST is standard-less in terms of integration and implementation. There's no standard that describes even the format of data being exchanged via REST, unlike SOAP. SOAP requires XML, REST is ambivalent - you can do what you want.
When you interact with a SOAP service you know what to expect - it's always the same: WSDL, XML, SOAP envelopes/headers. When you interact with a REST service it's another story. POST? GET? Query string? Data formatted in ... what? JSON? XML? TEXT?
The standards wrapped around SOAP make integration and reuse much simpler than REST, even though the actual development of REST is much easier.
I'm not against REST at all, to be honest. Love it, use it often, think it's great. Same with SOAP. I'm just against the argument that REST is "simpler" and "less costly" than SOAP because it really isn't. The cost and complexity with REST is just found in different places than it is with SOAP.- JRahm
Admin
We've just gone through the SOAP vs REST debate at work while deciding to add a web API to our product, and SOAP won. It may not be pretty or as elegant on the wire as REST could be, but there is library support out there and things like WSDL to aid in adding a new client in a different language or framework.
With REST we're back in the game of protocol development (yes, XML is really just the transport for the custom application protocol), but SOAP gives us a fixed format in terms of message envelope, data types, constructs, etc. I'm confident in this decision, and I'm the one who developed the current proprietary protocol to avoid having to map into an existing protocol - mind you, SOAP was young back then. - Lori_MacVittieSOA isn't dead, but its standards are
