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.