I’ve noticed in the last little while that there seems to be a trend happening with web services: people think SOAP is too complex. I keep coming across articles and comments talking about how web services are just over engineered. I have to say, I totally agree.

Here’s some excripts from a c|net article:

A debate is raging over whether the number of specifications based on Extensible Markup Language (XML), defining everything from how to add security to where to send data, has mushroomed out of control.

Tim Bray, co-inventor of XML and director of Web technologies at Sun Microsystems, said recently that Web services standards have become “bloated, opaque and insanely complex.”

This isn’t something that’s new. An onlamp article from 2003 talks about how people use REST over SOAP:

While SOAP gets all the press, there are signs REST is the Web service that people actually use. Since Amazon.com has both SOAP and REST APIs, they're a great way to measure usage trends. Sure enough, at OSCon, Jeff Barr, Amazon.com's Web Services Evangelist, revealed that Amazon handles more REST than SOAP requests.

Personally, I've always gone with so-called REST interfaces if I have a choice. I've in fact been using REST for many years, without realizing it was called REST (the term, which stands for Representational State Transfer, was coined by Roy Fielding in his doctoral dissertation in 2000).

Put simply, SOAP just requires so much setup and overhead to do what should be a simple task. As a programmer, I like to actually make working code, and I hate writing tons of ‘helper' code that essentially doesn't actually do anything. That's what I feel like I'm doing when working with SOAP and writing WSDL schemas and all the extra junk. There are APIs to make things eaiser, but in the end it's still an over-engineered protocol.

REST keeps it simple, with really no formal definition. It's more a method than anything else. Go to a URL, get a bunch of data back. Talk about simple.

Advocates of REST push that you should only even use normal HTTP GET requests for retreiving data (as opposed to POSTing a complex XML query like SOAP does). This makes sense, as one of the ideas behind the web to begin with is that any piece of information can be obtained with a URI. This makes REST rediculsly simple, and for this reason some people hate it, others love it. It definately makes thing easy to debug, as you can test responses in your browser.

Most REST services return a response in XML, but they don't have to. If all you're trying to get is one piece of information, it's just as easy to just return that information in the body, with no tags at all. The querying application doesn't even have to parse anything. Obviously this has it's downfalls (like not being easy to returning error conditions or multiple values), which is probably the reason reponses are usually XML. Of course it helps that there are XML parses available for virtually every language, including JavaScript. In fact, REST is basically what drives most AJAX applications.

Of course, SOAP is XML and therefore human-readable as well, but let's look at the diferences with a small example.

SOAP example

This is an example SOAP request for getting the price of a product.

Request:

  POST /SOAP HTTP/1.1
  Host: www.ecommercesite.com
  Content-Type: text/xml;
  charset="utf-8"
  Content-Length: nnnn
  SOAPAction: "Some-URI"
  
  
  

    <SOAP-ENV:Envelope
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
    SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <SOAP-ENV:Body>
    <m:GetMarketPrice
    xmlns:m="Some-URI">
    <symbol>PART304285</symbol>
    </m:GetMarketPrice>
    </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>
  

Response:

  HTTP/1.1 200 OK
  Content-Type: text/xml; charset="utf-8"
  Content-Length: nnnn
  
  
  

    
      <SOAP-ENV:Envelope
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
    SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
    <SOAP-ENV:Body>
    <m:GetMarketPriceResponse
    xmlns:m="Some-URI">
    <Price>50.25</Price>
    </m:GetMarketPriceResponse>
    </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>
  



  
  

REST example

Just a simple GET query:

GET /REST/getprice?symbol=PART304285 HTTP/1.1
Host: www.ecommercesite.com
Content-Length: nnnn

and the response:

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8″
Content-Length: nnnn

50.25

<p>
  Considering they both do the same thing.. which one looks simpler?
</p>

<p>
  Of course, for a REST service to be useful, just like any other API or tool, it needs to be well documented. This means documenting the request parameters, all the things it can do, as well as all the output formats. SOAP has WSDL that I guess provides this information (to a point, and assuming you know enough to make sense of it all), but I don't think that feature alone is worth all the other baggage SOAP carries.
</p>

<p>
  To be honest, I also only have limited experience using SOAP (for the reasons that I've outlined in this entire post), so I'm quite willing to hear arguments to convince me why SOAP could be more beneficial than REST. At this point however, I can only conclude that SOAP is just over-engineered. Why bother coding all that extra junk when you can just REST? :)
</p>