Just like many others, for quite some time now, I have been familiar with the RPC (remote procedure call) interfaces, be it the proprietary COM and .NET remoting or a more standard and interoperable SOAP interface developed using any technology. I had never dared to see what the so called ‘RESTful Services’ are until one of our current projects forced me to take a look at it and find out what it is. The journey became quite fascinating when I started understanding what REST is all about and comparing it with SOAP and other RPCs, particularly the total shift in the mindset that a normal developer would need to undergo to create a RESTful service.

If you are unfamiliar with SOAP or any RPCs in particular, we shall see that with a brief example.

SOAP RPC

Generally all RPCs are ‘action oriented’. In fact, most of our programming models are ‘action oriented’. What do you mean by that? Take the scenario in which you are developing a CRM application and you are tasked with developing a CRM SOAP service. You need to list down all the customers from the DB. If the user selects one customer from the list, then you need to give a detailed view of the customer data and allow the user to create/update/delete etc. That’s a pretty normal CRUD scenario. If I ask what would be the public interface of such a CRM service, I am sure most people would jump at the following interface

 

Customer[] GetCustomers()
Retrieves all the customers in the DB
Customer GetCustomer(int custId)
Retrieves the details of the given custId
Bool CreateCustomer(Customer customer)
Creates a new customer in the backend with the supplied Customer object
Bool UpdateCustomer(Customer customer)
Updates an existing record

It’s quite straight forward, isn’t it? Now, let’s see how the same scenario unfolds with RESTful services.

RESTful Services

The main difference between REST (Representational State Transfer) and other models is that REST is ‘resource oriented’ rather than ‘action oriented’. The other important difference is REST’s reliance on the standard web protocol, HTTP. The best example of a REST service platform is none other than the web or WWW. If you build your service exactly similar to how the web works, then your service becomes a RESTful service.

Just think for yourself how the web works

  • For example, you open the browser, type www.google.com and enter. You see the home page of Google. What have you done here? You have issued a ‘GET’ HTTP command for a resource. Here the resource is, possibly a file on the disk. That is, the home page file on the Google’s web server.
  • Assume you are creating a Gmail account for yourself – you type in all the required data and submit the form. That means, you have issued a ‘POST’ HTTP command for a resource, possibly RegisterUser page or something similar in the Google server.

Do you get the idea? If you use a HTTP verb command (GET, POST, PUT, DELETE etc.) over a resource then you become ‘REST’. The resource could be anything that is uniquely identifiable by a URI like a web page, a video, an image, a PDF file, an entity like Customer – just about anything and everything.

Let’s apply the same concept for our CRM service. You will first identify all your resources, fix the URIs to uniquely identify the resources and then decide on the HTTP verb that the resource is going to support.

 

Resource
URI
HTTP Methods
Customers (root resource)
‘/’
GET (gets all the customers)
Customer
‘/{custId}
GET, PUT, DELETE (you want to get a particular customer details, create a new customer or update an existing customer or delete a customer)

 

Note: the URIs are relative here. The absolute URI will look something like the following

http://www.mycrm.com/ (all customers will be listed)
http://www.mycrm.com/CUS000123/ (for a particular customer)

Hope that gives you a fair idea of what a RESTful service is all about.

Why REST is becoming popular and more and more people are adopting REST, including Microsoft?

  • REST uses the standard HTTP web protocol. HTTP has got a lot of built-in capabilities like authentication, caching, content negotiation etc. When you use REST, you get all those benefits for free.
  • REST has an uniform interface: with 3 or 4 methods you define every operation that brings in a greater amount of simplicity.
  • Since it’s HTTP based, both the server and client become stateless that makes your system perfectly scalable (i.e. the HTTP request or HTTP response has got all the details contained within itself, so the client or server doesn’t need to maintain the state).
  • All systems that support the standard HTTP protocol support your service, too. It’s more interoperable than SOAP.
Now we come to the important question of SOAP Vs REST
 
SOAP Vs REST??
 
When this question is raised, an alert and safe architect would answer something like this – “it depends”. That’s the standard answer and here, it’s quite correct, too. I believe you need to make the right choice keeping your current problem domain in mind.
  • For simple CRUD operations REST makes perfect sense, but for a complex domain the resources that you carve out may not simulate the real time. For example you may need to consider ‘money transfer’ as resource in the banking domain whereas our logical mind tells us it’s more of an operation. It’s a disadvantage to me, but for some people it’s the simplicity – “I am able to define all my behaviors with a few well known HTTP verbs”.
  • SOAP tool kits are not supported in all platforms, while there are no such problems for REST as it’s HTTP based.
  • For REST, the transport layer is fixed, that is HTTP. For SOAP you have many options like TCP/IP, NET PIPE etc., including HTTP.
  • SOAP supports sophisticated security standards, but with HTTPS, REST may be giving a close competition.
I do not wish to sell one over the other because I am myself not influenced by any one of these models, in particular. I perfectly agree with the response ‘it depends’.
 
Tags: Technology | Comments Off

previous post: Are you ready for the cloud? next post: User Experience

Comments are closed.

Archives

2016
2015
2014
2013
2012
Congruent Facebook Twitter Slideshare