Awhile back, IT Business Edge's Ann All sent me a piece about REST versus SOAP. I'm not sure why, probably it mentioned SOA, but quicker than you can say "service-oriented architecture" three times, I'd replied that there was no way I was touching THAT debate with a 10-foot pole.
You see, I know a religious war when I see one. And as I see it, that's a battle for developers.
But here's the thing-recent intelligence from the field suggests that REST may be winning-if any one approach really wins such things - and at the very least, there are some recent developments of which IT leaders should be aware.
I actually wrote about one development earlier this week, when I shared that two signatories of the SOA Manifesto recommended REST and HTTP for creating service interoperability. Of course, they weren't talking specifically about REST versus SOAP, but rather about how REST and HTTP could be used instead of ESBs.
That was an interesting data point, but what really tipped the scale was a recent post by James Governor, aka Monkchips, an analyst with RedMonk.
Now, if you're a business person and not in IT, there are two things you should know before we continue:
1. REST is a software architectural style, not a language.
2. You can create Web services that follow the REST style, but when people refer to WS-*, they mean Web services that are SOAP-based. (You might also want to check out our Knowledge Network entry on Web services.)
So, to continue, Governor attended IBM Software Analyst Connect, which apparently is where analysts are debriefed on all things IBM. And what Governor discovered is that IBM has shifted its WebSphere and other application integration and middleware solutions to REST:
"While some have variously said SOA is Dead, or we need to rethink everything and move to Web Oriented Architecture IBM had just pragmatically introduced the notion of RESTFUL SOA. Why not just integrate resources in much the same way you integrate services? Why make things hard for developers?"
Governor is not a fan of the SOAP-based WS-* approach to SOA. He seems to see it as a shortcut, a cheat of sorts, that's kept organizations from achieving real value with SOA.
His post also includes a REST call-to-action (I know: It does sound like a paradox) for IBM:
"But just because IBM is now taking advantage of REST and more lightweight integration methods doesn't mean its customers are. IBM's main education efforts in SOA were about the style that is now being superceded. IBM customers are usually two to three, if not four to five, years behind current state of the art. Its time for IBM to start beating the drum for the new development and integration style."
It's unlikely IBM's shift to REST will settle the whole REST versus SOAP debate, since SOAP has a heavyweight of its own: Microsoft and its popular SharePoint.
The bigger takeaway here, at least for IT leaders, is whether REST gives you a stronger SOA deployment-with easier integration and more reuse of services (read: more agile) than you'll get from an SOA built on an ESBs or the SOAP-based WS-*. Assuming the SOA REST crowd is right, you also have to ask yourself-could investing in RESTful developers and training help with SOA's ROI?
It's too promising to ignore.