Web Forefront

Before you jump the gun on the lesser "advertised" XML/HTTP REST approach as not being a web service, the fact remains that it complies with a web service definition : The capability of accessing information in a platform transparent manner. And if you consider the thorough REST support offered by early web services adopters like Amazon and EBay, you can conclude that REST is not a fad.

The most obvious difference between both approaches is the actual payload that is transferred through the wire, which directly translates into distinct implementation details on both client & server. Lets explore the differences.

A REST design implies that a web application is equipped for returning a plain and simple XML fragment as a response to a URL request. Lets assume you make a call into the following address: http://www.yoursite.com/restapp/weather.php?city=sandiego. A REST type application would return a payload like the following snippet back to the caller:

<weather>
  <city>San Diego</city>
  <date>05/21/05</city>
  <high>85</high>
  <low>70</low>
</weather>

It's that simple, the server side application is implemented in PHP -- or any other language for that matter -- and can be called & interpreted from any type of client because the payload is XML. Now lets analyze the SOAP approach and see how its different.

For starters, the actual client call to a SOAP enabled service is not as simple as attaching your parameters to the URL -- like a typical POST done by an HTML form -- the expected payload by the processing server has to adhere to a SOAP schema, like the following :

<SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   
  <SOAP-ENV:Body>
         <ns1:getCityWeather xmlns:ns1="Weather">
           <op1 xsi:type="xsd:string"> San Diego </op1>
         </ns1:getCityWeather>
    </SOAP-ENV:Body>
  </SOAP-ENV:Envelope>

Sending this payload to the server implies a more extensive client design process, and receiving a response also requires provisions to process a SOAP payload instead of a plain XML fragment.

You may now be asking yourself which approach is better and under what circumstances, here is my take on both designs.

If you see the capability of publishing some business data to your clients so they can process it in something other than a browser as a nice feature, then using a REST design could be a wise choice. Using XML over HTTP you shed yourself of other web services issues like dealing with WSDL and UDDI, in part because REST is so simplified it doesn't require these enterprise type services.

For example, being a wholesaler and publishing catalog data to retailers via a web service is a nice feature to have, but it is not something that a retailer can't do without if unavailable for a few hours or a day. What I am getting at with the previous example is that the caller of the service can afford to reissue failed attempts without any consequences.

Take Amazon and EBay they offer REST access for their product information, news feeds like Atom and RSS are also designed around REST, their primary characteristic is that even though the information can be consumed by and device or process, the consequences of multiple calls or failures is not transcendental.

A SOAP structure is complex in nature for a reason : resilience. Even though the previous SOAP snippet did not show it, a SOAP payload can include a series of service characteristics like priority, expiration, security credentials, routing information and transactional behaviors.

These types of policies included in your service call or response are all but essential in some cases. Any value added transaction is a candidate for using SOAP's provisions, a financial operation is an obvious case, another would be an order fulfillment done through web services.

Using SOAP also brings you into the circle of using web services contracts -- WSDL ("Web Services Description Language") -- and the capabilities of publishing them to a central directory -- UDDI ("Universal Description, Discovery and Integration") -- both of which are also a central part of using web services in an enterprise type setting.

If your intent on using web services is to publish non-critical data, a REST design can speed up your development time with workable tradeoffs, on the other hand, if you see web services as a cornerstone to your business, then you might as well bite the bullet and use the SOAP approach.

Update: Published a lengthier article on REST - Simplicity in Web Services design , that includes more technical differences to a SOAP stack and references to REST's use in production environments.