SOAP or REST?

Two programming experts say users should take the best of SOAP and REST to create service environments.

LAS VEGAS – So, which style of service enablement is better: SOAP or REST?

A pair of programming experts tried to put that debate to rest March 27 during a talk at The ServerSide Symposium here. Ted Neward, founder of Neward & Associates consulting and training company, and Brian Sletten, a partner with Zepheira, a Web 2.0 enablement and software development shop, argued the benefits and drawbacks of both Simple Object Access Protocol and Representational State Transfer.

Sletten and Neward discussed the benefits of Web services and how the vision behind them is solid in the goal to deliver reusable business functionality, platform and language independence, asynchronous processes, coordinated business systems, long-running transactions, and multipartner orchestrations and integration.

However, "reality bites," Sletten said. Instead of the nirvana expected under the vision for Web services, many users have been met with mass confusion, artificial complexity, competing visions, unmet interoperability promises, expensive failures and modest successes, he said.

Yet, there were many things Web services got right, including that loose coupling is a good thing; businesses run asynchronously; partner systems must communicate predictably; language bindings are necessary, but supporting multiple languages is just as necessary; and schema enforcement is a good thing, Sletten said.

Overall, the two said Web services are fundamentally a business value proposition.

Meanwhile, SOAP came out of the blocks running, with support from the Worldwide Web Consortium, vendors and users. It delivered language and platform independence, schema verification, synchronous/asynchronous invocation models, Remote Procedure Calls support and messaging support. However, the WS-* stack—pronounced WS star—which governs the SOAP-based services, led to some dissatisfaction because of factors such as complexity, lacking addressability and cacheability, and security issues, Sletten said.

Meanwhile REST is an architectural style for network software systems to promote scalability, generality, performance and extensibility. It also has a focus on information resource manipulation and a separation of concerns. However, some observers say REST offers too many degrees of freedom, Neward said.

Sletten and Neward recommended that developers take the best of both worlds. Where SOAP reigns is in systems needing industry standards, in leveraging existing infrastructure, in vendor support, partner interoperability, and transactional systems that span applications and partners, Sletten said.

"One of the biggest holes in the SOAP spec is the lack of cacheability," Sletten said. "Part of the reason our app servers are pounding the hell out of our databases is because they can't say 'I've already done that.’  [With REST], once a question is asked … I can come back five minutes later and ask the same question and not have to call all of that infrastructure.”

Where REST succeeds reigns is in managing information spaces and logical connections, data access control and regulatory compliance, homogenous layers over heterogeneous systems, cache-friendly interactions, and architectural migration, Neward said.

But the world is not totally either or in the case of SOAP and REST.

"The vendors have realized they screwed up and they're trying to steer the Titanic," Neward said of the SOAP-backing vendors. "This is not so much a technical issue as a cultural issue. REST is an architectural style; it's not a set of APIs or a set of language bindings. We're starting to see a melding of these two worlds.”

"The SOAP spec is starting to act more REST-fully," Sletten said, noting modifications being made to the SOAP specification.

"At the end of the day, what we want here is for these two concepts to align gracefully," Neward said.