RESTful Service

Initially, no one has supported to develop the RESTful service but Google has understood that the thesis submitted by the Roy-Fielding and publicly announces that we are going to RESTful services which makes the integration efforts easy, then all the industry people starts using the RESTful services hence Sun Ms. also supported the RESTful services.

For example, Google Geo-location (Google maps) has been completely RESTified.

In order to develop the RESTful services we need to use the set of principles that are provided by the Roy-Fielding so that integration becomes easy and along with we need some API that has been provided by Java so that we can develop the RESTful services easily.

Sun Ms. has provided JAX-RS API to develop the RESTful services and provided one JERSEY JSR 311 as a Reference implementation for the JAX-RS 1.0. But it has been not successful that’s where it releases JAX-RS 2.0 with more features and provided Reference Implementation as JERSEY (JSR 339) bcz API’s are always partial.

Similar for JAX-RS 2.0 there are several implementations

Implementations for JAX-RS:

JAX-RS API 2.0 (Stable version in May 2013)

|-JERSY (JSR 339)

|-RESTeasy (from JBoss)

|-Apache CXF

|-RESTlet

|-WebSphere Application server from IBM

|-Web Logic Application server from Oracle

|-EverREST

Some of the API’s which not Implementation for the RESTful are API some of they are

|-Swagger (Not Implementation for JAX-RS rather it is 3rd party)

|-Spring MVC

Support of Java to develop the RESTful services:

RESTful services can be developed any other protocol but the JAX-RS API is built or developed by Sun Ms. based on the Http only hence we need to use Http only so JAX-RS API doesn’t supports for any other protocols apart from Http.

The minimum JDK required to develop the RESTful services is JDK 1.5 bcz RESTful is extensively relays on the Annotations hence we need to use minimum JDK as 1.5 in modelling our RESTful service or RESTful Resource or Resource class bcz 1.5 only Annotations are introduced. 

The basic set things we need to develop web services and RESTful with comparison:

Endpoint (Servlet/EJB)

Documentation (WSDL)

Approach (Contract Last or Contract First)

MEF

MEP

But in case of RESTful services all these are not required bcz Http protocol we always need Endpoint as Servlet only but not EJB hence there is no concept of choosing an End point. Hence we can use Servlet/Filter who can receive the Http req and forward the req to a Resource.

Here there is no service documentation that means there is no WSDL hence there is no Contract so we don't have approaches in developing the RESTful hence there will not be any Endpoint.

There is no standards in RESTful that means we send any data format hence we don't need any MEF.

If we send the req we get response to know the status of the req that means Http is synchronous Hence there is no MEP.

Hence we can start our RESTful Resource directly as follows.

Use case:

DTDC Courier exposes their business Resources to the Local Courier Vendors as RESTful services:

There is an Local Courier vendor who is famous in a city or state but he don't have a business expansion throughout the India or world but DTDC Courier vendor is the one who is very popular shipping the goods to the entire world that's where Local Courier vendor's will ties-up with DTDC Courier so that Local Courier vendor takes the goods from the Local peoples and shifts to the DTDC so that both will gets benefitted bcz If DTDC wants to take the Goods to ship he has to maintain the offices and workers so if accepted the goods from the Local Courier vendor who is very popular so that he can get the bulk amount of goods at one single shot without any maintenance by maintaining office with customer care executives at local places that's where DTDC will ties-up Local Courier vendors and ships the goods across the world and if any goods comes to that city they will directly forwards to Local Courier vendor so that they will takes care of maintenance and serving to the customers, But in order to get the check the status of the Couriers by the Local Courier vendor customers whether the goods delivered properly or not DTDC should provide the info of the Courier delivery details but they should not give the DB details that is the reason they expose in the of Web Services/RESTful Web Services so that Local Courier vendor can display the details to their customers so that Local Courier vendor's customers uses their Local Courier vendor web sites without any problem and they can have trust on their Local vendor sites.

DtdcCourierVendor

|-Web site (specific to the Dtdc vendors customers)

LocalCourierVendor

|-Web site (specific to the Local vendors customers)

 Here why need a RESTful or Web Services means if Local Courier vendor dispatches goods using Local Courier vendor then he can comfortably tracks the status of Goods by using Local Courier vendor site only but by the DTDC bcz he is not the customer of the DTDC rather he is the customer of Local Courier vendor that's is the reason he will refers to the Local Courier vendor site but if Local Courier vendor talks to the web application of the DTDC then he will gets the response as text page and displays details with DTDC web page which is unknown to the Local Courier Customers that is the reason DTDC need to expose their business to the Local Courier Vendor as RESTful or Web services so that Local Courier vendor takes that business details and he can display to his customers with their own web site so that customers will feels satisfaction and bcz of this automation DTDC can avoids the Frauds by the Local Courier vendor as well bcz Local Courier vendor will saves the data in to the DTDC so he can avoid the fraud management as well bcz there is no manual intervention in shipping the goods.

Steps to Develop RESTful with the help of RESTful principles:

1. Create a Resource

2. Develop/Model the Resource Based on the principles 

(i) We need give URI to access the Resource hence we need to use @Path which is coming form JAX-RS API

(ii) The end-user need not know what are the resources/methods are there in the Resource class bcz it follows Uniform, Constrained Interfaces (interface means not java interface rather is an way to access the resource) principle so if we annotated with Http methods to corresponding method operations like @GET to get the details then client can access the resource without knowing the details of the resource class methods so @GET is called as Http designator and similarly annotate remaining methods with Http designators.

The client can send the data any format over Http req and client can send the data in multiple ways to the server. We will get interoperability bcz Http is there any where hence if we send the Http req then we can access the Resources bcz Http will not restrict data formats or standards so who ever cable of sending Http req they can access hence it is interoperable.

Ways to send the data to server over Http req:

1. Http header

2. URI (Path param or Query Param or Matrix param etc)

3. Http Request body 

If it is GET req we cannot send the data over the Http body bcz body will not be there for GET hence in case of GET we can send the data over Http either using Http header or URI.

If are sending the data over the Query params then we need to annotate with @QueryParam bcz Resource RESTful can take data in 3-ways so we need to tell in which way it needs to take the req data.

Using URI:

/dtdcCourier?agentNo=233&&trackingNo=A132

(iii) So now the server can access send the response and in case of GET it can send the response as part of Http response Header or Http response body but not over the URI bcz URI is used to send the req but not for response. By default GET will places the response as part of body. 

In case of SAOP based services xml will sent over the SOAP body but in case of RESTful services it can take any data as input and any data as response. Hence in case of RESTful it is the responsibility of the Resource to specify the response type or format bcz a Resource can give any format as response hence Resource need to tell the response format using @Produces(text/plain) so that client can understands and displays to the users which is called as Representation-Oriented. The text/plain or xml or excel these are called as MIME types or Media types.

@Path("/dtdcCourier")

class DtdcCourierResources {

  @GET

  @Produces(“text/plain”)

  public String getCourierStatus(@QueryParam("agentNo")String agentNo, @QueryParam("trackingNo")String trackingNo) {

    return "Status: for " + trackNo + " is under process";

  }

}

The Resource we developed which is JAX-RS complaint hence without changing the code from one Implementation vendor to another Implementation vendor we can develop the RESTful services which is called as Agnostic to The Implementation vendor and with simple modifications of that vendor specific Run-time we can switch easily from one vendor to another Implementation vendor without changing our Resource class.

The Resource that we developed is an POJO class hence it cannot know how communicate over the network hence we need one agent which is capable receiving the req over the network and sends the response over the network that’s where we need to use Servlet/Filter which is called as RESTful JAX-RS Run-time And the Run-time is specific to the Implementation vendor.

Generally we will take Servlet as Run-time and if req comes to the Resource the Servlet cannot takes req directly hence we need to configure Servlet URL as same as URL pattern of Resource class using Wild-card patterns.

 If Servlet (JAX-RS Run time which specific Implementation vendor) has to forward the req to the corresponding Resource class it has to take the extra path URI that is after the ContextRoot and then searches for the URL with matched Resource URL by scanning all the Resource classes who are annotated with @Path and forwards to the that Resource class.

Some Implementation vendors provides Servlet and Filter also and some other Implementations will provides Servlet as Runtime. That means Bootstrapping mechanisms (Configuring JAX-RS Runtime which is specific to Implementation) changes from vendor Implementation to Vendor Implementation vendor but Resource that we developed always will be same irrespective of vendor Implementation.

Note:

The convention we need to follow in developing the RESTful is name followed by Resource but not the Service.

Whenever we annotate a class with @Path then it is called as Root Resource class.

Why are u naming RESTful as Resource?

As RESTful is not surrounded with any restriction like Web Services we can access this as like normal hence we need to name it as Resource.

Differences between the GET and POST:

GET will not have any req body but POST will have an req body. Hence we can send data over Http header or URI in case of GET and in case of POST we can send in all the ways.

Summary:

If we develop the JAX-RS API Compliant based RESTful services then we no need to change the code from one Implementation to another Implementation bcz we will refer to the JAX-RS API provided interfaces, abstract classes and annotations but not the Implementation vendor specific classes or interfaces or Annotations. Hence switching between one vendors Implementation to another vendor Implementation is easy and we need to change the Run Time of the specific Implementation vendor.

Difference between JERSEY and RESTEasy Implementations:

RESTEasy:

JBoss RESTeasy is an Implementation for the JAX-RS API and that works with only JBoss Application Server only out deployments will not supports that means if we develop the application using JBoss it will not works in other containers and in order to work without side deployments servers JBoss has provided some additional jar dependencies. Even though they provided the jar dependencies to deploy in any container but it most of the features works better with JBoss only like security works better with JBoss server only.

When we are working RESTeasy with JBoss Application server we no need to download binary distribution bcz JBoss itself by default contains the binaries.

JERSEY:

JERSEY is an Reference Implementation that is given by Sun Ms. (Oracle) and it works with any Application server or Servlet container (like Tomcat, Web Logic, WebSphere, Glassfish, JBoss etc) bcz JERSEY is completely JAX-RS API compliant that is the reason industry preferred to work with JERSEY rather JBoss.

Glassfish server by default supports for the JERSEY Implementation hence when we are working with Glassfish we no need to download the binary distribution.

Why you are using JERSEY?

(i) It is completely JAX-RS API complaint. 

(ii) It works with any application server that means agnostic to the application server.