Explaining SOAP and REST to the BizDev team

With all the EHRs that our engine interacts with, it's kind of hard to keep track of what all the connection types and data formats we support are. As always, I try to help clarify things.

This post will be about the largely philosophical differences between SOAP and REST and why they occupy the places they do in healthcare IT.

A note on protocols

One of the fundamental techniques of computer science is abstraction. You don't need to know how the code behind your apps works to use the app, and in turn the person who wrote the code doesn't really need to know how iOS works, and the people who wrote iOS don't really need to know how the A9 processor works. The idea that you only need to know the layer right below you is fundamental to the technological wonder world we live in. Networking follows the same model, and wikipedia has a decent page describing the OSI model. 
Most of what we do is layers 6 and 7, since most people have already written great libraries to handle levels 1-5.

Things that SOAP and REST have in common

• Both are most commonly used over HTTP/HTTPS (but it's not required for either)
• Both are ways to get data from EHRs. The EHR will have made a design choice in deciding whether or not a peice of data is available via SOAP or REST.
• Both are often used with an external authentication framework. This is how you identify who you are when accessing the SOAP/REST service. SOAP services tend to use ws-security and REST tends to useOAuth, but there aren't any rules.

Why would I use SOAP?

Puns aside, the key differentiator for SOAP is more flexibility than REST, which it trades for added complexity. Oftentimes a SOAP web service is paired with a WSDL which is needed to describe the SOAP endpoint. SOAP makes no rules about what you send in a SOAP message, just that you provide enough information to make things work. It was also pushed heavily in the early 2000s as the way to send data over the web - which is why we see it everywhere in healthcare.

Metaphor: I like to think of SOAP as throwing a big giant Katmari Damacy ball at the receiver. It will look like a big pile of random junk, but the receiver will probably know what do with it.

Why would I use REST?

REST is a much more opinionated way of exchanging data over the web.The original definition is actually pretty easy to understand, as it lays out a few basic principles. The most important of those today are:

• Uniform Interface (all data has a URL and we use a limited set of instructions to operate on them)
• Stateless (when I PUT something in it's place it is as I say it is)

REST is currently employed by EHR vendors like Athena and Allscriptsand most notably is the architecture of FHIR, which all EHR vendors may eventually adopt. There is nothing about REST that doesn't jibe with healthcare data in particular, but we are already many many years behind.

Metaphor: Think of REST like throwing a baseball full of data. It's always going to look like a baseball from the outside, but the inside will be different for each different endpoint.

Why do we say Redox has a REST-inspired API?

The author of the REST defintion, Roy Fielding, would probably call BS on this term.

We do not follow several principles of the REST architecure because we think we've found an even simpler way for your app to start consuming healthcare data, today.

The vast majority of Healthcare data exchange happening today is not stateless, and has only one verb: PUT. To make your life easy we've taken the least common denominator and offered a promise: whatever the architecture of healthcare data exchange, Redox has you covered.

Sign up for Redox to read about our data models and our getting started documentation, and see what REST-inspired really means.