My friend and colleague, Mike Stamback, had some really good comments on my previous blog post regarding the SOAP vs. REST decisions that enterprise architects face on a daily basis. His comments really got me thinking and rather than responding to his comment, I wrote up this blog. His verbatim comments were:
"Nice thoughts Maneesh. What's the practical impact of a hybrid approach though? Can SOAP-y and RESTful services coexist and interact with each other? It seems there might be some implications on transformation, translation, security, etc since these two patterns are different. Any thoughts on that?"
SOAP and REST have to co-exist and the decision to use either should entirely be use case driven - SOAP for secure, reliable interactions, REST for more light-weight interactions. Standardizing on one over the other is like taking the one-size-fits-all approach; and we know how ridiculous the one-size-fits-all idea was.
There are always going to be cases in hybrid environments where a business process needs to orchestrate across a variety of services, some SOAP-y and some REST-ful. This is where either the orchestration engine needs to have rich enough capabilities to handle both types of invocations or will have to go through an intermediary (service virtualization or mediation) that takes care of the necessary translations, transformation, and security as Mike has rightly pointed out. This validates Mike’s concern about having implications on transformation, translation, security etc. Which also means there’s going to be penalty one will have to pay for choosing to expose a service using one protocol over the other.
There really is no right or wrong answer here. Some of the considerations besides the functional needs (security, reliability) are:
- This is when one has to resort to the age old 80-20 rule to figure out which service is exposed over what protocol. What is the preference of 80% of the clients that are invoking this service? Would they prefer SOAP or REST?
- If one decides to go via an intermediary due to client-service mismatch, what are the maintenance and monitoring overhead costs of this extra moving part?
- Performance impact
(a) What is the impact on performance of the service provider because of the overhead of having to handle SOAP headers?
(b) What is the impact on performance of the client because of the overhead of having to handle SOAP headers?
(c) What is the performance impact due to the additional steps – serialization/de-serialization, translation, transformation, security policies etc. – introduced because of the intermediary?
Like everything else in life, it all boils down to what your priorities are – is it functionality? is it lower TCO? is it performance? or is it the requirements of your most important client? Sometimes you have to bend over backwards to keep your most important customer happy.
Comments (3)
Here as some more points to consider when choosing between SOAP and REST:
* Want to find your data? Use REST
* REST is a distributed data model
* Tim Berners Lee on LinkedData
Posted by andrej | April 8, 2009 12:35 AM
Posted on April 8, 2009 00:35
One comparison between SOAP and REST is service contract, which is critical when considering service composition. WSDL is much clear and strict in this perspective, payload is strictly bound to xml schema. WADL doesn't really define the output data format, which can be anything, though majority is xml or json. So SOAP based traditional SOA is much easier to be consumed and automated, as such we see a bunch of ESB products, but few, if any, available for REST composition.
Posted by Richard Yin | May 12, 2009 5:54 PM
Posted on May 12, 2009 17:54
Thank you for the article, Maneesh.
If I didn't know better, I might think you were having flashbacks of a particularly difficult customer in your last two sentences.
As ridiculous as it was/is, I do believe many customers choose a one-size-fits-all approach for services (among other architectural choices) for a variety of reasons. One of the most common reasons I have found is a lack of knowledge/experience in order to make informed choices -- in many ways, these are the same reasons why groups tend to choose a single development language/platform/pattern. I think we have all come across the person(s) who can [claim to] implement anything using XYZ. This will continue to be the case as smaller organizations (with limited resources) dive into new areas like SOA -- at least new for them and their staff.
Along with education, I believe it takes someone sticking their head out there for that first proven ROI to begin opening minds. Let's hope our community's articles like these and discussions help in the process.
Posted by Ashok Aggarwal | July 27, 2009 10:57 PM
Posted on July 27, 2009 22:57