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'

IT orgs will lose control over IT budgets in Future: Gartner

IT budgets and responsibilities are moving out of the control of IT departments and into the hands of others, Gartner says in its vision for 2012 and the coming years. Any idea who are the 'others'?

It's the business managers and business users. The business community feels empowered like never before particularly with the advent of 'Cloud' and 'Mobility'. Business users have started improving their productivity with devices, tools and applications of their choice, in many cases without consulting the IT. In the changed techno-political scenario,  IT is forced to legitimize the devices and tools that the business user started using without IT's guidance and direction. In the past, the same business user would wait endlessly for the IT to come and provide the 'right' tools or even the ERP that influences the life of a business user. And they used to work with whatever's been provided by IT even though they are not exactly happy.

Those times are gone now and the main trend that is forcing this change is the increased consumerization. With the smart phones, tablets, social networks and cool apps, business users are forcing the IT to fall in line or become irrelevant in the enterprise technology landscape. CIOs lose control over the devices and applications that the business user consumes and ultimately on the IT budget as well. In future enterprise wide IT budgets will be fought over by many a business units, the performing business unit will get the bigger pie. IT would need to keep pace with the business users and consumers and be tech savvy or face the risk of becoming sidelined.

When the public clouds become the mainstay, users will have the increased tendency to approach the help desks of the cloud service provider by-passing the enterprise IT

Is this good or bad?

• This is extremely good news for small and medium IT service providers (vendors).  They always find it difficult to make an entry into enterprises mainly because of the CIOs love for the large scale vendor that provides all the possible services required by the enterprise though quality is something that needs to be desired
• This will provide an opportunity for niche IT service providers (someone who specializes in SharePoint or mobile or CRM and the likes). This results in high quality technology solutions
• Business-IT alignment won't be a big problem like before. Since it's the business that demands the IT capabilities, there will be less of business-IT alignment problems in future. It's not the IT which is imposing its whims and fancies on the business
• Technological innovations will sneak into enterprises rather quickly resulting in rapid ROI
• Business users will be the change agents rather than the IT 

What's the role of future IT orgs?

One flip side that I see with the trend is, there may be a lack of holistic IT strategy for the enterprises that may result in islands of apps and tools incompatible with each other.  Each business unit (particularly powerful, performing business units) will influence the technology landscape which they may not be well aware of. Here's what IT will have a role to play

IT and the CIOs will have to take more of a governance role. They envision the IT road map- be it the infrastructure architecture or data architecture or the application architecture. Business can choose the solution they think would help them accomplish their business objectives and create value for their customers, but within the contours of the roadmap set by IT

Except for the above, I don't see any issue with the predicted change. I welcome it.