Web services debate: SOAP up or REST easy?

By Alex Handy

December 1, 2008 —

The veterans of holy wars past line the repositories with their dead, and from the CORBA faithful to the Amiga maniacs, the technology world is rife with standard bearers unwilling to concede the fight. Now, as Web services and SOA eye the advance of Web 3.0, a fresh conflict is roiling the Internet: SOAP vs. REST.

Of course, the battle lines here aren’t as clear as in most religious conflicts. For starters, SOAP is a strictly designed set of protocols and rules for ensuring the integrity and security of network transactions that will be using the Internet as a transport. Representational state transfer does not carry the weight of surrounding standards, such as the WS-* specifications that give SOAP its teeth. But that also means REST is much less governable.

It’s not entirely an apples-to-apples comparison, said Rod Johnson, creator of the Spring framework and a member of the Java Community Process executive committee. Spring is only just now adding REST support, but already it’s won him over.

“We certainly see a lot of growth in REST. We are building significant REST support features into Spring 3.0, and it’s one of the features our community most requests,” Johnson said. “I think recent economic events will really help REST.

"IT departments are looking to cut costs. They really need to look toward simpler solutions. Complexity is a luxury you can afford in good times.

“Certainly, one of the things that stands out about REST is that it’s very simple. Despite the ‘simple’ in its name [Simple Object Access Protocol], SOAP isn’t that simple.”

SOAPy enterprises
Randy Heffner, analyst at Forrester Research, said the battle for Web services is not a new one.

“The conversation has been going on in the industry since 2005. What’s changed since then is the level of the conversation, but not the dynamics,” Heffner said. “Sometimes the conversation gets turned into SOA vs. REST and Web-oriented architecture. That’s a wrong-headed argument, because we’re missing protocols and perspective. SOAP and Web services are two different things.

“SOA is design of application capabilities and services. SOAP is a protocol for accessing services. It’s the same with REST. You can’t feed this notion that REST somehow means we’re not doing SOA.”

Heffner said SOAP tends to be associated with formal business systems, while REST is typically for the consumer-facing technologies of Web 2.0. Those associations come with good reason, he said: SOAP offers security and reliability controls, while REST does not.

“The issue has been, and continues to be, that there is no one working on interoperable profiles for how to do REST with high quality of service,” said Heffner. “You put together your own proprietary configuration, like what the Web Services Interoperability Organization is doing: They take SOAP and wrap other specs around it. It has a basic security profile that says how to do secure services with SOAP.

“On the REST side, one might say there’s HTTPR for reliability and HTTPS for security, but there’s nobody putting together a profile that says, ‘Here’s how to do these things in an interoperable way.’ ”

Thus, enterprises that count on their Web services for business-critical information cannot turn to REST for fear of losing important packets or having them fall into the wrong hands, Heffner said.

As for the simplicity, new tools from Eclipse and Microsoft have blunted the WS-* specifications’ sharp edges.

“One of the things that has changed over the years is that the WS-* specifications are being built into the tooling, so if I am using Visual Studio or Eclipse, the tooling is rich enough that actually I don’t see a lot of that WS-* junk. It gets hidden from me by the tooling,” Heffner said. “A lot of complaints about complexity are misdirected. There are plenty in the REST world who say that real code soldiers don’t use tools. And that vocal crowd says, ‘I can’t deal with all this WS-* stuff in a text editor.’ Well, no, you can’t.”

In truth, it is not SOAP that is complex, but rather the WS-* specifications that go along with them. Those SOAP wrappers bring new encumbrances that add reliability, security and interoperability layers on top of the protocol. While the standards give businesses the integrity they need from their data, they’re not the sort of stuff service developers favor, said Heffner.

Thus, REST has taken its place among the Web 2.0 and blogging crowd, where IDEs are often not used to build Web code. SOAP historically, on the other hand, has been used by the enterprise crowds that use VisualStudio and Eclipse.

SOAP’s not for Vim
Spring creator Johnson is not convinced that tooling will save SOAP from working up an incomprehensible lather.

“I’ve always been a bit of a skeptic about tooling solving complexity issues of that magnitude,” he said. “Tooling is fine when it exists to make something faster and easier—when you can still do it without the tool. [However,] it’s a slippery slope when you say, ‘This is too complex to do by hand, but we have a tool.’ ”

Johnson said tooling can’t save a project from complexity creep. “Over the lifetime of that software project, complexity is going to crawl back out from under the carpet. I think there are additional, more-advanced capabilities covered in the SOAP world. But I would expect much more rapid growth for REST,” he said.

Rob Cardwell, vice president of development for open-source middleware provider JBoss, thinks the two protocols today are in near-perfect balance.

“I think it’s safe to say that both approaches have merits,” Cardwell said. “Some areas have turned into a bit more of a religious argument. There is an awful lot of overlap between the two. To solve certain problems, you might be able to use both approaches. From a company perspective, if you took a poll of everyone at the JBoss Middleware Group, it’s probably a 50-50 battle between the guys who prefer Web services and those who prefer REST.”

As for the argument that tooling can make SOAP much easier to use, Cardwell said, “That’s a more recent argument. Web services have been around for a while. Even though that’s a valid recent argument, you still have a number of developers who fall into the category of once burned, twice shy. Once they’ve been down that path, and frustrated when the tooling wasn’t there, it may not be easy to go back at it.”

All three men did agree on one point: The battle between REST and SOAP is far from over. Said Cardwell, “I think the dust has to settle a little bit, and people will see what the predominant model turns out to be.”

Related Search Term(s): REST, SOAP, Web development

Share this link: http://www.sdtimes.com/link/33086

Letters to the Editor: Sun gives REST, SOAP choice A reader takes issue with a headline on our story about Sun working with REST along with SOAP, while others weigh in on rewriting Java code in C and solving impedance mismatches.

Short Takes: Lack-of-oil-driven software development Our editors go over the ways you can shorten your commute through technology, reactions to Yahoo's rebuffing of Microsoft and Snow Leopard's appearance at the Apple WWDC, and the winner of SAP's Project Green contest.

From the Editors: Keep watching the clouds Just because Amazon's EC2 is the first cloud platform to hit the market doesn't mean it is insurmountable, as Google and Microsoft hope to overtake it. Also, both REST and SOAP have their benefits and drawbacks, so developers should figure out on their own which best fits their needs.

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST