REST & RESTful service, and why use REST

REST is Representational State Transfer. A client-server communication over HTTP. REST service is indeed a service with all service features like -
1. Platform independent
2. Language independent
3. Standards based - runs on HTTP.
4. Can be easily used - standard HTTP actions
with some benefits over SOAP services -
1. REST can be consumed by any client - even web browser with Ajax and JavaScript
2. Its light - doesn't requires XML parsing and doesn't require a SOAP header
3. SOAP is old and REST is newer
4. Common actions - HTTP GET, POST, PUT, DELETE
5. Every API behaves same - so everyone likes it.
6. Technologies of REST are well understood.
7. Its cool - Google, yahoo, amazon, twitter, flickr, uses it,
8. REST is how web should be - stateless, cache-able.

Some things where SOAP will get precedence over REST -
1. Operations represent logic
2. Very loose coupling
3. Designed for distributed architecture, computing - loosely coupled distributed messaging
4. Very much standard(WSDL) with lot of WS-* guidelines and even standard error messages
5. Supports stateful and asynchronous calls.

But if you ask me the features of SOAP which are not present in REST are the reasons why we use REST.
We don't need arbitrary operation names, arbitrary actions(verbs).
We need to handle the tight coupling in REST, we can have minimal inter-dependencies in REST client an server, also sometimes the tight coupling results in optimized design(sometimes), and minimizes redundancies.
Right now we assume a Client-server architecture and don't think about lot of distributed systems.
We hate standards when they are too much. I don't like complex service descriptor WSDL.
And how many times we use Stateful, Transactional and asynchronous SOAP web services. Web services are most of the times assumed to be stateless and synchronous. But if you need complex system with stateful, transactional, and asynchronous web services then you should go for SOAP.

Before we start with some more theories about REST, lets look at some basic concepts -

  • HTTP
  • J2EE Design & Layered Architecture
  • SOAP to REST

  • Browser is the client and web server gives response. An HTTP client opens a connection and sends a request message to an HTTP server; the server then returns a response message, usually containing the resource that was requested. 
  • HTTP is used to transmit resources, not just files. A resource is some chunk of information that can be identified by a URL. 
  • After delivering the response, the server closes the connection - Stateless, No transaction. 
A HTTP Request -
GET /path/to/file/index.html HTTP/1.0
GET is the most common HTTP method/action/verb; it says "give me this resource".
The path is the part of the URL after the host name, also called the request URI.
The HTTP version always takes the form "HTTP/x.x", uppercase.

A POST request is used to send data to the server to be processed in some way. Its different from GET.
  • There's a block of data sent with the request, in the message body. There are usually extra headers to describe this message body, like Content-Type: and Content-Length:.
  • The request URI is not a resource to retrieve; it's usually a program to handle the data you're sending.
  • The HTTP response is normally program output, not a static file.
                        J2EE Design & Layered Architecture

After few years of inception, J2EE architecture was based on MVC. And it was success and its still very widely practiced. And in J2EE we used jsp, servlet, ejb and dao layer. We were writing these and divided them in to layers. And communication was happening like - 
JSP --> Servlet --> EJB --> DAO --> DB. And we can divide them in separate boxes, Like below - 
Source -
But in actual when any architect was designing a system, he or she was thinking about many design patterns and several layers came up, means apart form presentation, business, and dao,  many layers arised for many concerns like security, loose coupling, and to adhere to design patterns like service locator, business delegate, facade, etc. We saw many design patterns for J2EE application - 
Source -

To follow design patterns and for separation of concerns, we came up with multiple layers, so I am desining a Hospital application i can assume of few layers, irrespective of some decisions like I will be using which framework, I will be using which ORM. But at least I can assume there will be a 
  • DAO/ORM layer
  • Business layer to hold business logic along with several business objects &mappers
  • Service facade layer to expose business logic as web service or probably as session facade
  • Executer layer to call services along managing transaction, logging, and other aspects. 
  • Controller/Action layer, where request will come first
  • Presentation layer consisting of JSP or now xHTML. 
I am assuming I have been given a task to design a Hospital application and considering the past experience, practices, patterns I have below design in mind - and design is irrespective of technologies i will use - 

So, I have a hospital application which allows to book appointment.
Probably, I will follow below major steps -
1 - Create DB. Write DAO/JPA layer. Write a business layer over it. Write web service over it. Name operations according to functionality like openSlots, bookSlot, etc. Generate WSDL and give to client application. Also we will have to add mappers to map service request/response to Business Objects, DTO's,/Entities.
2 - I will generate Client stubs using WSDL and import in my client application. I will also have controller and executer layer to call web service and to process browser requests. And mapping Form bean's to service request and response.
I designed the application but it seems to me very complicated and very difficult to maintain and extremely troublesome to explain any new developer who joins when application is ready -
1. Mapping actions. Mapping HTTP action to controller and then mapping controller to executer to web service call and so on.
2. Mapping objects like form bean to service request to business objects to entity.
3. Many layers.
You can say why are we have web service layer here.  But since re-usability was in my mind -
Assume, We have two applications, one which is used by customers and one is used by staff and both will have only: presentation + controller+executer only. Both applications will call common service's. Thats why I have kept service layer and beyond in separate application.

                                  SOAP to REST

Why not think of directly calling the web service form HTML. And map the HTTP action like POST, GET to actual Database opetation's like Select, Update.
When I call GET the webservice is called which fires select in DB and return just one row.
When I call POST the webservice is called which fires select in DB and updates just one row.
When I call DELETE the webservice is called which fires select in DB and updates just one row.
we use the row as object for all communications so that we never map. Directly pick the row from DB and pass the entity to form, and form directly updates the Entity and calls POST and row is updated in DB.
Presentation also made easy we just convert the entity in JSON when passing to browser, and browser returns JSON which is converted to Enitity.
So, why not directly communicate with SLOT table directly get rows and update a row. 
We will have to services which return actual resource and directly talk to resource not to some operation which will further call some layer to update the resource. 

So, we started thinking of moving from SOAP to REST.
This thinking is similar to -   Richardson Maturity Model  (must read)
Read more about the maturity model on -
Martin flower has explained in much more simpler words -
And there is very informative implementation of REST on -

In my next post I will build a REST application in Spring.


Popular Posts