This site uses cookies and by using the site you are consenting to this. We utilize cookies to optimize our brand’s web presence and website experience. To learn more about cookies, click here to read our privacy statement.

The RESTful story – Why? (2 of 3)

Continuing from the previous post, let’s look into what are the big benefits that the REST architecture style provides.




There is a huge push for moving to REST and for good reasons, such as:


While SOAP provided transport neutrality there were doubts and debates about performance & scalability of SOAP based services. REST on the other hand came with all the benefits of HTTP and RESTful services can scale as easily as Web applications. In addition, since SOAP has it’s own message structure there is a dramatic difference between a SOAP based HTTP request and an HTTP request transporting the same amount of application data. See the messages below:

Example SOAP message over HTTP


POST http://wcftest.azurewebsites.net/Service1.svc HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8; action=”http://tempuri.org/IStockTicker/GetQuote”
Host: wcftest.azurewebsites.net
Content-Length: 168
<s:Envelope xmlns:s=”http://www.w3.org/2003/05/soap-envelope”>
<GetQuote xmlns=”http://tempuri.org/”>


HTTP/1.0 200 OK
Content-Length: 187
Content-Type: application/soap+xml; charset=utf-8
<s:Envelope xmlns:s=”
<GetQuoteResponse xmlns=”

Example of RESTful message:


GET http://webapitest.azurewebsites.net/stocks?symbol=msft HTTP/1.1
Host: webapitest.azurewebsites.net


HTTP/1.0 200 OK
Content-Length: 5
Content-Type: application/json; charset=utf-8

Multi platform support

Integration with native application was a drawback for SOAP. All the browsers, phones, tablets, Xbox,  set-top boxes… understand and support the HTTP stack, that means, they can send and receive http requests and know how to manipulate HTTP supported content types. That is a huge benefit with REST, it enables your services to cater to a wide range of clients.


Focus on Resource with a Universal Interface/Contract – SOAP, although arguably not meant for it, has been used for RPC based development approach. Where as REST approach focuses on resources, and the actions on those resources are defined by http Verbs. In case of REST, the interface or contract of your service is universal and HTTP based. ALL the actions you can take against your resources are:

GET         (Retrieve)

POST       (Create)

PUT         (Update)

DELETE  (<—)

Some sample Request URLs:

GET http://MyOnlineShop.com/Products – Get all products

GET http://MyOnlineShop.com/Products?id=8765 – Get a specific products

POST http://MyOnlineShop.com/Products – Create a product (with the fields data in the request)

REST architecture talks about returning resources and links to navigate to associated resources. This is exactly how the Web works: You go to a web page, it has a content of its own, and links to navigate to related content.

Simplicity – Calling an HTTP service is very easy, compared to a SOAP based services like WCF. No WSDL or  Service utility tool is required. The fact that it can be called via JavaScript using just the URL and knowing the HTTP verb says all about the simplicity of RESTful services.

Cloud computing and push from industry leaders – Because of its scalability, multiplatform reach, simplicity, etc., REST has been adopted by all cloud computing platforms; and other SAAS from Microsoft, Amazon, Google, Salesforce, etc. have embraced it. Some companies have dropped SOAP services but most support both. Commonly used social services like Facebook, Twitter, LinkedIn, etc. provide both REST and SOAP services. It’s  fair to assume that services created to be consumed at that extent will prefer the consumers using REST.


Using REST is not the end of SOAP. By no means does this post imply that SOAP or SOAP based frameworks are not required anymore.

To decide what you want to do, you need to analyze what you want in your services:

  • Do you need to use transport protocols other than HTTP? Remember some channels like TCP or Named pipes are much faster than HTTP if your service will be consumed within same OS environment or on the same machine.
  • Do you need message based security?
  • Are you dealing with Message Queues?

Among other considerations if the answer to any of the above three questions is yes, you are probably better off using SOAP services.

In the next post we will be talking more about the frameworks available to build RESTful services and which ones to use.