Brandon Smith

REST vs. WSDL

31 July 2006

Steve over at NetKernel has an interesting take on the current state of Web services (the WSDL kind). It is the latest, and certainly not the last, that is helping me to shape my thoughts around the whole REST vs. SOAP/WSDL or REST compliments SOAP/WSDL debate.

Steve's comments are in reaction to Simon of salesforce.com and Sanjiva of the WSDL spec.

Simon explains that the reason for returning an ID twice is related to the object model of the XSD, and goes on to fault the WSDL to Source tool chain for being differently quirky on every version.Sanjiva blames Salesforce and believes that someone took a nasty class hierarchy and auto generated XML Schema and WSDL out of it

Steve: Developing on the Edge - No, blame whoever uses WSDL

In all fairness, WSDL 2.0 does allow for HTTP bindings. But the way it is laid out in a separate document, it seems more orthogonal, not a baked into the WSDL 2.0 spec.

The question I have to keep asking myself is whether the surge of REST popularity is "raging against the machine" of SOAP/WSDL and the like, or is it because it is actually more natural to use RESTful interactions? In other words, has REST become to mean anything that is not SOAP? In many ways, I think it has.

From my view (which is a rather low perch, might I add), there are three types of REST. Many only claim two, but I think they forget about the "REST because it is not SOAP" crowd:

  1. High REST: I also call this "Unicorn REST" because, in the words of Don Ferguson, this type is a little bit more common than unicorns. This is REST as laid out by Roy Fielding. It makes use of all the HTTP verbs and has a completely stateless server. Status codes are these developers best friends.
  2. Low REST: This is the people's REST. REST for the rest of us! This looks at how web applications have been designed over the last 10 years and challenges the thinking. It still may have some state on the server, but its developers are judicious about it. Often, the HTTP POST method is overloaded with interactions that would normally use PUT and DELETE.
  3. REST because it is not SOAP: This group of developers don't care about Roy Fielding's dissertation and are not interested in better, scalable designs using the HTTP protocol. All they know is that a SOAP stack can be complicated. They claim REST when they mean simple XML, and oh yeah, get and send over HTTP, too.
Is this third group valid? Are there any more? REST has become overhyped beyond what Fielding intended. I think it has changed they way many approach web application designs, but the second it became a buzzword and not an aspiration, it lost its meaning.