Last week, I shared how SOAP may be holding back enterprises when it comes to Web-oriented architecture. Some say most APIs online are based on REST and suggest the solution is a more "RESTful" enterprise.
But there's another side of the story being championed by Steve Jones, global head of master data management for Capgemini and a SOA practitioner.
In a recent InfoQ interview, Jones contends that REST isn't ready for the enterprise integration while defending SOAP against claims it's "too complex." Jones says:
Enterprise Integration is about separation of domains to enable them to work independently with well defined boundaries. These boundaries are often contractually enforced via outsourcing deals or technically enforced by package vendors. RESTs mentality is that these boundaries are fluid and that making them rigid is a problem, the reality is that having ridged boundaries is actually a good thing as it enables teams to work independently. Thus the ability to publish a functional contract (the WSDL) which can be consumed in multiple technology stacks is a key benefit of SOAP/WS-*.
7 Steps to Smarter Integration
Sometimes, change can be worthwhile. The key is knowing what's worth pursuing and what's not.
In other words, REST doesn't require or give enough formal definition for enterprise integration.
It helps to understand the difference between REST and SOAP. For the non-techies, REST stands for "Representational State Transfer." Wikipedia describes REST as a style of software development used for "distributed hypermedia systems," like the Internet.
SOAP stands for "Simple Object Access Protocol," although increasingly the acronym stands on its own. It's a protocol specification, which basically means it's pretty defined and formal in how it's used - for exchanging information when you're doing Web services on networks. One of the main points of conflict is that SOAP relies on XML for its messaging format, so if you want to converse with SOAP, you've got to use XML or provide a workaround.
This is my best stab at understanding and explaining the conflict between the two: REST Is more of an attitude towards negotiating between systems. It's a more fluid way of interacting. SOAP, on the other hand, is not so much an attitude as a very specific way of communicating that, by its very formality, makes communication simpler, harder and formal - like a legal contract. It's fine, there's little room for misunderstanding and the terms are literally spelled out, provided you understand contract law and want to communicate that way. So, SOAP, by its nature, moves you away from the nature of REST. (For an excellent and more precise history, check out Paul Prescod's "Roots of the REST/SOAP Debate.")
When you understand the difference between the two and their goals, it's not hard to see why SOAP is the darling of the enterprise while REST is favored on the Web.
REST fans like to say SOAP's too complex, but Jones disagrees. He actually sees it as easier when your goal is enterprise integration:
Blaming SOAP for the complexity of B2B and Enterprise Integration misses the point of where the complexity comes from. The complexity comes from the need to integrate multiple different business domains and a standard lack of core business and technology approaches (such as MDM) which would make this easier. The technical plumbing approach is just the bit that shifts XML across the wire, SOAP makes this EASIER than older approaches and so its reduced complexity. REST hasn't made it easier so it's not being used.
Those who favor REST say this criticism is unfair; they claim REST hasn't been adopted because enterprises are slow to catch on to new approaches.
You could go back and forth on this issue ad naseum, and it looks like the two sides plan to do just that.
But there's also a third criticism that contends it's ridiculous to boil the issues down to "two warring factions." You'll always find that there are more moderate thoughts in the readers' comments.
So, where does this leave you, organizations and businesses that want to do what's right internally but also want to start moving to a more Web-oriented approach?
Unfortunately, I don't think this debate has offered much guidance on that front yet. Jones didn't really address that question in either his InfoQ interview, in his first blog post on REST in the enterprise - with the unfortunate metaphor of REST as "stillborn" - or in his most recent post about how REST could become more enterprise-friendly. In general, the discussion turned away from ReadWriteWeb's original, excellent integration question.