The RESTful story – Why? (2 of 3)

 

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

 

 

 

Why REST

 

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

Scalability

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

Request:

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">
    <s:Body>
        <GetQuote xmlns="http://tempuri.org/">
            <stockTicker>MSFT</stockTicker>
        </GetQuote>
    </s:Body>
</s:Envelope>

Response:

HTTP/1.0 200 OK
Content-Length: 187
Content-Type: application/soap+xml; charset=utf-8
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
    <s:Body>
        <GetQuoteResponse xmlns="http://tempuri.org/">
            <GetQuoteResult>28.33</GetQuoteResult>
        </GetQuoteResponse>
    </s:Body>
</s:Envelope>

Example of RESTful message:

Request:

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

Response:

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

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 enable your services to cater to a wide range of clients.

Focus on Resource with a Universal Interface/Contract – SOAP, although arguably was not meant for it, 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 link 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, it has been adopted by all cloud computing platforms and other SAAS from Microsoft, Amazon, Google, Sales force 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.

Disclaimer:

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

To decide what you want to do you 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 question 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.