Monday, December 14, 2009

Observation on REST vs SOAP

Last week was especially frustrating. The technical topic of the week was REST vs SOAP, but what was not obvious to most observers is a frustration that has NOTHING to do with REST vs SOAP. You might be seeing this frustration on the faces, the emails, the voices, and the blogs of those of us who spend a majority of our time participating in OPEN and CONSENSUS processes. We place ourselves on the mercy and critique of others multiple times a day. Everything we do is included in openly published minutes, draft documents, ballots, ballot-comments and such. Our names are well known, our addresses and phone numbers are well known.

Along comes this nameless and faceless "community" that somehow gains power by coming to the party late and simply having an advocate appointed to a high office. These people are not involved in the many years it has taken to develop the standards. These people can not be communicated with. Their ideas are taken without question. We have no idea who they are. Even Vinton Cerf and Aneesh Chopra are names without any way to have a discussion with. I applaud John Halamka, even poking fun at/with him. I applaud John because he is approachable and forward. It is very hard to have the same respect for others that don't participate but simply throw FUD into the process late in the game.

Most of the discussion around REST vs SOAP has been this faceless "community" complaining that the HITSP selected standards for communicating clinical documents (XDS/XDR) is SOAP based. We hear that they want a RESTful equivalent. The first problem is to find a RESTful "standard" or "profile" that has been built in an open and consensus process. This specification is not just going to drop out of thin air. A highly important point is to make sure we have the requirements clearly identified. The Open and Consensus process is good for uncovering all of the requirements and making sure they are satisfied before we start to have hundreds of developers building products and networks based on that specification.

This is very different than what OHT and FHA-CONNECT have done by publishing a RESTful interface to these tools that speak using the HITSP selected standards on the backend. This kind of a RESTful interface is local and doesn't impact anyone outside of the local (which can be large) developers. I would really like to be sure that the existing specification is truly not sufficient before we create-new specifications that we then call parsimonious.


  1. John, could you lay down a challenge for RESTful folks? What does SOAP do that HTTP + TLS does not? If we can get beyond generalities to specifics it would help to advance the discussion.

  2. WHY do those of us that have used an OPEN and CONSENSUS process to come to a SOAP solution need to justify our work, again? Why is it not the other way around, that the RESTful people come forward and declare why SOAP is not a good solution where RESTful is better? I believe that I made it clear that this is what I am asking them to do. Come forward into the light…

    I know what you are saying, and am trying to do this in different threads. The hard part is not coming up with the reasons, but putting them in terms that the ‘audience’ can understand. Where the audience is those poor folks caught in-between those with opinions on the topic.

  3. John, I too look forward to see how this turns out.