REST Vs SOAP RPC

I had been familiar with the RPC (remote procedure call) interfaces for quite sometime just like many others: be it the proprietary COM and .NET remoting or a more standard and interoperable SOAP interface developed using any technology. I never dared to see what is the so called ‘RESTful Services’ 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’s REST 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 in particular any RPCs 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. Pretty normal CRUD scenario.  If I ask what would be the public interface 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? 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

  • Open the browser, type www.google.com and enter. You see the home page of google. What you have 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 you, you are typing 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 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, 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 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 you would have got a fair idea of what a RESTful service is about.

Why REST is becoming popular and more and more people adopt 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. All those benefits you get for free when you use REST
  • 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 themselves 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 contemplating your current problem domain

  • 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- “with a few well known HTTP verbs I am able to define all my behaviors”
  • SOAP tool kits are not supported in all the platforms, no such problem for REST since it’s HTTP based
  • For REST the transport layer is fixed, that is HTTP. For SOAP you have many option like TCP/IP, NET PIPE etc. including HTTP
  • SOAP supports sophisticated security standards, but with HTTPS REST may be giving a close competition

I don’t want to sell one over the other, because I myself is not influenced by any one of these models. I am perfect with the response ‘it depends’

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