Tuesday, July 03, 2007


In the weekly newsletter from TheServerSide.NET, there was a link to an article titled "REST versus SOAP - the REST story" by William Brogden.  It's a few months old, but talk about the recent rise in REST types of services over XML-RPC and SOAP.   Brogden briefly covers REST, but he doesn't talk about the advantages of REST and why you would ever want to use it over SOAP.  It's obvious that he prefers SOAP, but the reasoning was left out of the article.

Having done SOAP and REST for accessing web services, I can see the where it's advantageous to use SOAP as opposed to REST (or vice versa).  SOAP is very chatty, but you can send complex data structures to the web service.  Development tools like Visual Studio or Delphi can can read the WSDL from the web service and that gives you the "intellisense" autocompletion functionality that can save a lot of coding time.

With REST, you access the web service with just the basic HTTP GET and PUT commands.  You compose a URL for your web method request and the service sends back a response.  The response is usually in XML, but that is dependant on the functionality of the web service.

The drawback with SOAP is that there is more overhead in the construction of the method request and with the parsing of the request on the web service end.  When you have a web service that is serving thousands of requests a minute or second, that overheard may not be needed.

For web services that have relatively simple data types, using REST can provide the functionality that is needed.  You also get the advantage of testing individual method requests from a browser as the method request is basic URL. 


  1. Actually you're missing the big advantage of REST. By sticking to simple semantics (especially if you limit yourself to GET as much as possible), it scales MUCH better as it can take advantage of all levels of caching between you and the server.

    Let's say for example you have a service that exposes the interface for an online bookstore. Assuming the inventory changes fairly rarely (once a day), properly structured catalog queries could stick in places like the local cache of the web client, a proxy cache on a corporate gateway and an edge cache in your geographical area. Now very quickly the browsing experience becomes fast for the users and low-cost for your core servers. To carry the bookstore analogy further, purchase events would likely requre POST instead of get, but they're significantly less frequent than browsing interactions.

    In this way, REST takes advantage of the existing scaling mechanisms the internet has grown on top of HTTP - something SOAP cannot do.

    Also, you can still include complex data in your payloads - you just have to manage interpreting it yourself instead of relying on a rich library layer to make it feel like some native type in your program.

  2. REST based architectures have a large amount of advantages over that of SOAP based architectures.

    REST is based on the contents of the URI (Universal Resource Identifier) and because of this it reduces the bandwidth usage. Furthermore, the outputs recieved from REST services, as you have mentioned, are main XML, this can be styled using a stylesheet called XSLT and for this reason makes REST known for its Simplicity.

    Other advantages you mentioned are very true in that the use of the URI for the method request allows testing and troubleshooting to be a lot easier, however I agree with ANON above who mentioned that REST takes advantage of all levels of caching between client and server.

    In summary, you have made a good evaluation of REST vs SOAP but key aspects seems to be missing. I think you have been more focused on getting across the simplist points however the greatness of REST vs SOAP is much more superior than you have mentioned.


Note: Only a member of this blog may post a comment.