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.
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.
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.