REST stands for Representational State Transfer.
According to the REST architecture, there are 6 constrainst which should be followed:
Client-Server
There should be a clear separation between a client and server.
Stateless
The client-Server communication is further constrained by no client context being stored on the server between requests. Each request from any client contains all of the information necessary to service the request, and any session state is held in the client. The server can be stateful
Cacheable
As on the World Wide Web, clients can cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client–server interactions, further improving scalability and performance. One more thing which differentiates as RESTful framework from other web-development frameworks is that generally all web-development frameworks rely heavily only on HTTP Get and Post Requests. While a restful leverages the maximum of http protocol. It uses all the types of http request(HEAD,GET,POST,PUT,DELETE).
For example - consider a scenario where you want to delete a product from a product list with product_id=111; The server side code for the same will be somewhat like this if a HTTP GET request is sent from client-browser with product_id=111 appended to the url.
public void doGet(HttpServletRequest request, HttpServletResponse response) {
String prod_id = req.getParameter(“product_id”);
Connection con = DBConnection.getConnection();
Statement st = con.createStatement();
st.executeQuery(“delete * from product where product_id=’”+product_id+”’”);
}
As you can see In the above piece of code, we are using a GET request to perform a delete operation on a resource. Therefore we are not using the real power of HTTP protocol. According to REST principles, the same could have been done by sending a HTTP DELETE request from client browser and at server side.
public void doDelete(HttpServletRequest request, HttpServletResponse response) {
String prod_id = req.getParameter(“product_id”);
Connection con = DBConnection.getConnection();
Statement st = con.createStatement();
st.executeQuery(“delete * from product where product_id=’”+product_id+”’”);
}
Similarly to read a resource – use GET – scenario – get product details create a new resource – POST – scenario – add a new product update a resource – PUT - scenario – update an existing product details get product meta information – use HEAD – scenario – reading the meta-information of products (say inventory information).
REST
REST is nothing but using the current features of the “Web” in a simple and effective way. If you see, some of the amazing features of the Web are:
•
40 years old matur
ed and widely accepted HTTP protocol.
•
Standard and Unified methods like POST, GET, PUT and DELETE.
•
Stateless nature of HTTP protocol.
•
Easy to use URI (Uniform resource identifier) format to locate any web resource.
REST leverages these amazing features of the web with some constraints.
Let’s define REST in official words, REST is an architectural style built on certain principles using the current “Web” fundamentals.
There are 5 basic fundamentals of web which are leveraged to create REST services.
Principle 1: Everything is a Resource
Internet is all about getting data. This data can be in a format of web page, image, video, file, etc. It can also be a dynamic output like get customers who are newly subscribed. The first important point in REST is start thinking in terms of resources rather than physical files.
Below are some examples of resources with URI:
- www.questpond.com/image/logo.gif (Image resource)
- www.questpond.com/Customer/1001 (Dynamically pulled resource)
- www.questpond.com/videos/v001 (Video resource)
- www.questpond.com/home.html (Static resource)
So the first thing is, visualize everything as resource.
Principle 2: Every Resource is Identified by a Unique Identifier
The old web identifies all resources by a URI. For instance, if you want to display customer with their orders, you can use www.questpond.com/DisplayCustomerandOrder.aspx. In REST, we add one more constraint to the current URI, every URI should uniquely represent every RESOURCE data.
For instance, you can see the below unique URI format for customer and orders fetched.
| Customer data |
URI |
| Get Customer details with name “Shiv” |
http://www.questpond.com/Customer/Shiv |
| Get Customer details with name “Shiv” |
http://www.questpond.com/Customer/Shiv |
| Get Customer details with name “Raju” |
http://www.questpond.com/Customer/Raju |
| Get orders placed by customer "Shiv" |
http://www.questpond.com/Customer/Shiv/Orders |
| Get orders placed by customer “Raju” |
http://www.questpond.com/Customer/Raju/Orders |
Simplification is the way to success and that’s what exactly the goal of uniform interfaces is. When external clients are interacting with web resources, they expect simplified interfaces.
For instance, let’s say you have exposed customer and orders data / resource on the web. Let’s assume below are the methods / function names by which external clients can communicate to your application.
Do the above method names look inconsistent and difficult to remember? Yes they do. Now what REST says is keep your interfaces uniform and simple. This can be achieved by using the uniform methods of HTTP protocol and combining the same with your resource operation.
Below is the list of HTTP methods for getting, creating, updating and deleting a resource on the web.
Now by combining the standard HTTP methods and your resource names, you can have uniform interfaces and thus leading to simplified communication. You can see from the below table how we have created uniform REST URL using standard HTTP methods.
| Normal Method names |
HTTP methods |
REST Uniform URL |
| AddCustomer |
PUT |
Customer/Shiv |
| InsertOrders |
PUT |
Orders/1001 |
| SelectCustomer |
GET |
Customer/Shiv |
| getOrders |
GET |
Customer/Shiv/Orders |
| DeleteCustomer |
DELETE |
Customer/Shiv |
| RemoveOrders |
DELETE |
Customer/Shiv |
| UpdateCustomers |
PUT |
Customer/Shiv |
Principle 4: Communication is Done by Representation
When you send any request or you get any response, you are actually sending representations.
For example, let’s say you want to create a new customer record, you would send some kind of representation as shown below using HTTP PUT.
<Customer>
<Name>Questpond.com</Name>
<Address>Mulund Mumbai</Address>
</Customer>
Once the resource is created, you would get a representation as shown below. The below representation says the customer questpond has been successfully created and if you wish, you can use “http://www.questpond.com/Customer/Questpond/Orders” defined in the “Next” tag to create orders for the “questpond” customer.
<Customer>
<Name>Questpond.com</Name>
<Next>http://www.questpond.com/Customer/Questpond/Orders</Next>
</Customer>
The above representation was in XML format. If you wish, you can also send and receive other presentations like JSON. For instance, below is a simple JSON snippet for creating a new customer record with name and address.
{Customer :{ Name:'Questpond.com', Address:'Mulund Mumbai'}}
Principle 5: Be Stateless
Every request should be an independent request so that we can scale up using load balancing techniques. Independent request means with the data also send the state of the request so that the server can carry forward the same from that level to the next level.
For instance, below are two simple representations, the first representation is sent for logging in.
<Login>
<Name>Questpond.com</Name>
<Password>sdkj#43445</Password>
</Login>
If you are logged in successfully you receive the below representation.
<Login>
<Success>true</Success>
</Login>
If you want to search for customer, you would send him the below representation stating that you are in a state of successful logging in and would like to search all customers.
<Customer>
<Filter>All</Filter>
<Success>true</Success>
</Customer>
In other words, every request is independent and the server does not need to remember your previous request and states.
The OSGi Framework is made up of three layers -- Module, Lifecycle, and Services -- that define how extensible applications are built and deployed. The responsibilities of the layers are:
