The RESTful story – What? (1 of 3)

 

In this 3 part post we will talk about REST, what it is (part 1), why has it gained huge popularity in recent years (part 2) and what are the frameworks that we might or might not want to use, depending upon what we are trying to achieve (part 3).

Where do we begin?

To start with a formal definition - REST is an architectural style for the Web, to build services hosted and consumed over HTTP. To understand that, lets look at something's that you see on most of the webpages you visit:

Each one of these icons have scripts that connects to a target service, like Facebook, Twitter, Google+ to start with. They would handle your authentication and invoke actions that the target service provides.

They are almost like multiple small apps running of the web page. These JavaScript apps are talking to some remote RESTful services. Google was one of the initial companies to completely drop their SOAP APIs.

The REST based service model is becoming rather inevitable with the evolution of cloud computing platforms. whether you choose to develop on Microsoft, Amazon, Google or other platform.

So to understand the shift towards REST, let’s talk a little about SOAP.

What is SOAP?

SOAP is an XML info set based messaging protocol. The big value it brought to the table was transport neutrality or “interoperability”. It is a protocol with a defined XML messages structure, having its own headers and body. These messages are capable of being transported, independent of the underlying transportation protocol.

SOAP was designed to be a remote object access protocol, inherently RPC based.

Understanding REST

REST (aka HTTP services or WEB APIs or RESTful services) is an acronym for Representational State Transfer. It is an architectural style for the Web, to build services hosted and consumed over HTTP. It’s a pattern that focuses more on resources than action. The only actions REST supports are the HTTP verbs – GET, PUT POST and DELETE and supports all the data formats that HTTP supports – HTML, JSON, XAM etc.

Just like the Web, it is stateless, cacheable and scalable.

So to Contract REST against SOAP:

• SOAP is a messaging protocol where as REST is an architectural style.
• SOAP messages can be transported over any transport protocol (HTTP, TCP, MSMQ, Named Pipes) where as REST uses HTTP as the transport layer.
• SOAP has XML based message structure where as REST uses HTTP request structure.

In the next post we will contrast between the two and try to understand why one is better than the other.