The RESTful story – What? (1 of 3)

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

Where do we begin?

Let’s start with a formal definition – REST is an architectural style for the Web, used to build services hosted and consumed over HTTP. To understand that, let’s look at somethings that you see on most of the webpages you visit:

Each one of these icons has scripts that connect to a target service, like Facebook, Twitter, Google+. They handle your authentication and invoke actions that the target service provides.

They are almost like multiple small apps running on 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 another 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 brings to the table is 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, used 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.