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”
HTTP/1.0 200 OK
Content-Type: application/soap+xml; charset=utf-8
Example of RESTful message:
GET http://webapitest.azurewebsites.net/stocks?symbol=msft HTTP/1.1
HTTP/1.0 200 OK
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:
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.
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.