Could SOAP Be Holding Back Businesses?

Loraine Lawson
Slide Show

20 Hottest IT Skills

These are the most in-demand skills over the last year, according to Dice.com.

Remember that whole SOAP (and WS -* Services) versus REST debate? No?


It was a huge issue when companies first started investing in SOA. At first, everyone embraced SOAP, but then REST became the "it" architectural style, particularly for the Web. By then, many enterprises were invested in SOAP, thanks in large part to Microsoft's SharePoint which, by the way, now supports REST Web services.


I remember. I even remember dismissing it as a "developers' debate." So did others, contending there was no debate because developers could use each as the situation demanded.


The debate seemed to end with the truce of sorts, with SOAP used primarily for enterprise SOA and REST for the Web. And that seemed to work fine for a long time, but over the past four years, REST has quietly, quickly and significantly passed SOAP as the approach most used in API protocol and styles.


Today, more than 73 percent of all APIs listed on the Programmable Web use REST, according to ReadWriteWeb. SOAP, on the other hand, holds a meager 17 percent of Programmable Web APIs.


What happened?


SaaS, cloud and all things Web-oriented embraced REST-ful Web services while enterprises stuck with SOAP. Now, businesses are locked into licenses, staff, tools, and legacy code all based around SOAP. And that doesn't seem to be changing. Recent job statistics show that SOAP ranked eighth among the top 20 most in-demand IT job skills this March. Meanwhile, Ajax, which uses REST principles, ranked 18th.


So who cares? How is this not a debate for developers?


It's no longer a developers' debate because it seems all this investment in SOAP could be keeping businesses from moving to the cloud, according to an article by Alex Williams of ReadWriteWeb. Williams' piece is based primarily on presentations given at Gluecon, a conference for architects, developers and integrators.


The article includes a slide from the recent Gluecon conference that quotes Gartner VP Nick Gall, who in 2007 explained the problem thusly:

Web Services based on SOAP and WSDL are web in name only. In fact, they are a hostile overlay of the web based on traditional enterprise middleware architectural styles that has fallen far short of expectations over the past decade.

So it's no longer a question of SOAP versus REST. The article contends it's now a question of whether SOAP is actually hindering enterprises from moving to a Web-oriented architecture. SOAP is not dead, Williams says. It's undead, and, like a zombie, it refuses to just die.


As you might expect, not everyone agrees with this thesis. There are a number of reader comments calling out writer Alex Williams and basically contending this is a non-issue, including this remark from "awilensky," who works at ECGridOS, an EDI solution provider:

This is a ridiculous argument, and is completely divorced from real world examples. API's, like our ECGridOS EDI Network management API, have 100+ functions, and require a uniform calling and security structure. Its not a candidate for REST, although we are planning on support of a higher lever subset of Post / Get carrying JSON data. This whole REST v. SOAP thing is good for editorializing, but does not address why SOAP is a better calling RMI in certain mission critical platforms, like EDI messaging and networks. And the fact is, that when a programmer is on the job and has made up their mind to get the job done, SOAP v REST is the smaller issue compared to larger and more important issues that impinge on the success or failure of a project.

Still, it seems there are some integration issues arising from this situation. It could mean organizations will need additional solutions to negotiate between SOAP and the very REST-based Web. Redmond analyst Michael Cote told ReadWriteWeb that there's already "a clamoring for tools and services that integrate the spaghetti bowl end points."


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.

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


Add Comment      Leave a comment on this blog post
Jun 2, 2011 5:49 PM alan Wilensky alan Wilensky  says:

I appreciate your kind reference. For people who would care to see the applied examples of why SOAP keeps things clean, just head over to http://ecgridos.net for code examples. And one more note: If the IDE handles WSDL well, there are no issues as far as developer workflow or efforts is concerned. I think of the REST v. SOAP editorializing is based on the frustrations birthed years ago, when the construction of WSDL was not fully automated by the Language Framework. Now, exposing a procedure is as easy as a click. Using the procedure is just as easy -  as we have found in supporting Java on Eclipse and Visual Studio programmers.


Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.

Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.