SOAP vs. REST and Common Data Transport

Recently there's been several discussions across many fronts on Common Data Transport which has re-energized the SOAP vs. REST debate. Although I don't specialize in infrastructure, I have developed both SOAP and REST-ful web services and would like to add my observations.

Arguments for both abound:

For REST-ful web services:

• can be called by a web page
• can be called from an XSLT Stylesheet (a restatement of the above, but with really useful ramifications)
• are easy to implement using off-the-shelf programming languages and libraries. A REST-ful webservice call can be implemented in a page or less of Java code in a single class.
• Can also be implemented using web page technologies such as ASP, JSP, PHP, et cetera.

SOAP Web Services:

• Have standards based and machine readable interface definitions (WSDLs) that can guide code generation. Most application development frameworks support SOAP.
• Support strong data typing in the information exchange.
• Support routing of web-service calls.
• Layers security into the protocol (e.g., WS-Security)
• Supports reliable messaging
• Are already supported by many healthcare standards

As usual when selecting tools, I would suggest that you select the right tool for the job. Let's take a specific example. Recently IHE created a specification for Sharing Value Sets. This specification is intended primarily to support an EHR's access to a collection of coded terminology. The profile oroginally suggested SOAP, and for various reasons, continues to include SOAP as part of profile. Some of these reasons are based upon the strengths of SOAP, which include the standards-based interface definition, strong data typeing and layering of security that are not readily addressed by REST.

However, there is one use case where this service can strongly support testing efforts that demands a REST-ful interface. IHE uses Schematron to test conformance of content to a specification. Many schematron implementations rely on XSLT. The interfaces defined by the SVS profile cannot easily be called if they support only a SOAP interface. The resolution by IHE was to support both REST and SOAP in the profile, and in noting that this was a "secondary" use of the profile, made REST an option. This was an easy decision because we obtained the benefits of both protocols for the different use cases, and the requirements of the two use cases were in fact different. The latter use did not have as strong a need for security or routing of the request. Testing efforts are done in a very different environment as is loading of vocabulary subsets into production EHR systems.

Yes, SOAP is more complex than REST, but with that added complexity comes added capability not present in the REST-ful framework.

My own answer to this debate is similar to the answer I give on any "religious war". My father told me regularly to pick the right tool for the job. Not everything is a nail, screw or bolt, so you need to have a toolbox that contains hammers, screwdrivers and wrenches. The guidelines I learned from my father were Hammer to nail, screwdriver to screw and wrench to bolt. Yes, you can hammer in a screw, or use a wrench to pound in a nail, but I've rarely been successful in tightening a bolt with either a screwdriver or a hammer -- for that I need at least a pair of pliers, and if I want it to stay fastened, a wrench.

The whole notion that there is "one-best-way" to communicate information flies in the face of everything I've learned over the last 40 years about tool selection. What is needed is not a common data transport, but rather, a common set of guidelines that we can use to understand how to best select a transport method for the problem at hand.