REST Web Services demystified

The cacophony
Recenlty, a lot of dissonance has sorrounded the debate betwee REST(Representational State Transfer) styled web services and SOAP. In fact, proponents of REST group have even gone to the extent of procaliming that it is quickly gaining ground and will one day become the de facto standard of creating web services, forcing SOAP into oblivion in the process. The internet is abuzz with claims that SOA (based on SOAP) is a thing of the past and WOA (Web Oriented Architecture based on REST) is the future. Not wanting to be left behind, the exponets of the SOAP, on the other hand, want to leave no stone unturned to prove the others wrong. Whatever the noises may sound like it makes sense to look into REST. So, here is the REST story

What are REST styled web services?
As already stated, REST stands for Representational State Transfer. REST basically means that each unique URL is a representation of some object. You can get the contents of that object using an HTTP GET. Other operations such as POST, PUT can be used to modify the object. In essence, REST it is the repsentation of the current state of a resource on the web.

The debate between REST and SOAP
While SOAP services are built on top of host of specifications laid down by OASIS, REST declares that the already existing WEB 2.0 standards are sufficient to build robust web services. Also, a major faction of REST supporters believe that using HTTP to piggyback payloads like SOAP does, is against the rationale of HTTP and an abuse to the protocol. It also brings in intricate complexities especially on the security front. One worth mentioning is piggybacking allows SOAP messages to get past firewalls and thereby places an additional constraint of detecting piggybacked payloads and scanning them prior to letting them in within the enterprise, which is not what firewalls are innately intended for. This is the main reason why both factions have always been at loggerheads with each other. More on this later.

Benefits of REST
Irrescpective of what the critics say there are some advantages that REST offers over SOAP. We shall now look at a few of them.

Simpler Interface
The REST methodology uses the URI(the way you send requests from your browser to a web site) for its implementation. Thus any request/response is a simple HTTP request/response. This keeps things simple, for nearly all applications on the web support HTTP. Thus, any application that supports HTTP can fundamentally produce and consume REST services. Contrast this with SOAP services, which have to adhere to specifications that go beyond HTTP thereby making it more complicated. Request/response are sent/received in SOAP envelopes which are XML that sit on HTTP for trnasport. So, there is the extra work involved in creating the SOAP request and parsing the response.

Light weight
From the above point it follows, that SOAP needs an additional XML wrapper above and over HTTP. This is unlike REST which is simple HTTP resquest/response. This can result in significant bandwith savings, especially for enterprises whose porfolio has umpteen applications interaction with each other at a massive level.

Security
Since firewalls are intended to restrict traffic by looking at the HTTP command in the request, it becomes inherently easy to apply security policies for REST services. For instance, if a GET operation was used, it can be considered safe since it can't, by definition, modify or alter data. It is here that SOAP can take liberties with the HTTP protocol. SOAP generally use POST and unless one has a good long look at the SOAP envelope, security apprehensions can't be put to rest. Since looking into SOAP messages is not a feature provided by fire walls, one needs to do extra work to enforce security at this level

REST service support in Oracle
In Oracle AS 10.1.3, you can use the command line Web Services Assembler (WSA) in conjunction with ANT or use JDeveloper (10.1.3) wizards to create and test REST services. The rest of the post describes how to create REST services with JDeveloper.

Creating REST services with JDeveloper
For the purpose of demonstration I shall use a simple class that concatenates one string with another and then publish it as a REST web service. Here is my class:

package com.nebulasky.blogspot;
public class HelloWorld {
public HelloWorld() { }
public String sayHi(String s){
return "Hello "+ s; }
}

Once this you have created the class, go back to the application navigator. Right click the context menu of the source java file and click 'Create J2EE web service'. In the second step of the wizard select the checkbox for REST Support (as seen in figure below) in the Java Web Service Wizard.



You can now click 'Finish' to complete creating the serb service. Deploy the service.

Testing the REST Service
You can test the process from the Enterprise Manager console by clicking on the 'Invoke REST POST' or 'Invoke REST GET'



Or you can even create the HTTP request and pass parameters using a query string. In my case it is
http://172.28.0.54:7777/BlogDemo-RESTHelloService-context-root/SayHiServiceSoap12HttpPort/sayHi?s=sankash

You should see something as this