SOAP versus REST battle still haunts us
Loraine Lawson just posted a thought-provoking piece, asking if SOAP is "holding back business." SOAP versus REST was an inside-the-datacenter developers' debate, but there's more at stake these days, she points out.
There's no question REST has been on the rise, especially among hot new online services. ProgrammableWeb's survey of 3,200 Web APIs For example, finds REST five times more prevalent than SOAP. Alex Williams raised the issue in his review of the buzz at the recent Gluecon conference, referring to SOAP as the "undead."
As he put it:
"Outside Gluecon's passionate circle of developers, SOAP is still used inside many an enterprise. So why is SOAP undead? Clay Loveless [at Gluecon] ...cited SOAP's complexity and the vendor wars that made tool chains a nightmare. The problem is that companies are still dependent on internal systems that have not modernized. They are dependent on SOAP. Investments have been made. 'All the tools, hires, licenses & codebase has been built around SOAP for a decade,' Loveless wrote on Twitter. 'Hard to turn on a dime.' SOAP's complexity also explains why many enterprises have been slow to move to Web Oriented Architectures."
Steve Jones came to SOAP's defense, noting that it addresses enterprise problems that REST isn't capable of handling yet. And, he adds, SOAP started effectively addressing enterprise integration issues more than a decade ago. "SOAP isn't complex, technically it might suck, but conceptually its simple," he points out:
"What SOAP did was solve a problem that the enterprise had. How do I describe integration interfaces so my systems on different technology stacks can communicate and do so in a way that enables my teams to work independently of each other. REST does not solve this problem in an effective way and bleating about "dynamic interfaces" being "better" misses the whole point of what has made B2B and Machine 2 Machine integration successful down the years, namely a focus on people-centric approaches rather than technical centric ones."
RedMonk's Michael Cote also damned SOAP with faint praise in Williams' article: "Existing applications that use it and Enterprise Architects who still want to enforce a top-down, well, architecture with it."
Here at the ZDNet Service-Oriented site, we take no position one way or another in the SOAP versus REST debate. Service oriented architecture and affiliated cloud formations should leverage services regardless of formats, standards, or protocols. That's what SOA is all about.
Still, as Loraine reminds us, SOAP versus REST may mean more hard thinking and choices are required to make it all work: "Organizations will need additional solutions to negotiate between SOAP and the very REST-based Web.... So, apparently what started out as a developer debate is now an integration and alignment challenge for IT. It's yet another reminder that even tactical decisions can have long-term strategic repercussions."