RESTful Web Services

What are RESTful Web Services

REST is used to build Web services that are lightweight, maintainable, and scalable in nature. A service which is built on the REST architecture is called a RESTful service. The underlying protocol for REST is HTTP, which is the basic web protocol. REST stands for REpresentational State Transfer.

RE-presentations in RESTful web services

RE-presentation once a resource is identified then its representation is to be decided using a standard format so that the server can send the resource in the above said format and client can understand the same format.

REST does not impose any restriction on the format of a resource representation.

Following are some important points to be considered while designing a representation format of a resource in RESTful Web Services.

• Understandability − Both the Server and the Client should be able to understand and utilize the representation format of the resource.
• Completeness − Format should be able to represent a resource completely. For example, a resource can contain another resource. Format should be able to represent simple as well as complex structures of resources.
• Linkablity − A resource can have a linkage to another resource, a format should be able to handle such situations.

Properties of REST architectural Structure

• Performance in component interactions, which can be the dominant factor in user-perceived performance and network efficiency.
• Simplicity of a uniform interface.
• Modifiability of components to meet changing needs (even while the application is running).
• Visibility of communication between components by service agents.
• Portability of components by moving program code with the data.
• Reliability in the resistance to failure at the system level in the presence of failures within components, connectors, or data.

REST architectural constraints

Client-Server architecture 

The principle behind the client–server constraints is the separation of concerns. Separating the user interface concerns from the data storage concerns improves the portability of the user interface across multiple platforms. It also improves scalability by simplifying the server components. Perhaps most significant to the Web, however, is that the separation allows the components to evolve independently, thus supporting the Internet-scale requirement of multiple organizational domains.
 
Statelessness

The client–server communication is constrained by no client context being stored on the server between requests. Each request from any client contains all the information necessary to service the request, and session state is held in the client. The session state can be transferred by the server to another service such as a database to maintain a persistent state for a period and allow authentication. The client begins sending requests when it is ready to make the transition to a new state. While one or more requests are outstanding, the client is considered to be in transition. The representation of each application state contains links that can be used the next time the client chooses to initiate a new state-transition

Cache ability

 As on the World Wide Web, clients and intermediaries can cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable or not to prevent clients from getting 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.

Layered system

A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers can improve system scalability by enabling load balancing and by providing shared caches. They can also enforce security policies. 


Code on demand (optional)

 Servers can temporarily extend or customize the functionality of a client by transferring executable code: for example, compiled components such as Java appletes, or client-side scripts such as Java Script.

How RESTful APIs work

A RESTful API breaks down a transaction to create a series of small modules. Each module addresses a particular underlying part of the transaction. This modularity provides developers with a lot of flexibility, but it can be challenging for developers to design from scratch. Currently, the models provided by Amazon Simple Storage Service, Cloud Data Management Interface and OpenStack Swift are the most popular.

A RESTful API explicitly takes advantage of HTTP methodologies defined by the RFC 2616 protocol. They use GET to retrieve a resource; PUT to change the state of or update a resource, which can be an object, file or block; POST to create that resource ; and DELETE to remove it.

Use of Spring MVC in RESTful Web Services.

In Spring MVC, a controller can handle the requests for all HTTP methods, which is a backbone of RESTful web services. For example, you can handle a GET method to perform read operations, POST methods to create resources, PUT methods to update resources, and DELETE methods to remove resources from the server.

In the case of REST, the representation of data is very important and that's why Spring MVC allows you to bypass View-based rendering altogether by using the @ResponseBody annotation and various HttpMessgeConverter implementations. By using this, you can directly send a response to a client, e.g. the resource clients want and also in the format they want.

Spring MVC also provides a @PathVariable annotation which can extract data from a URL. It allows the controller to handle requests for parameterized URLs.

 Another key aspect of RESTful web services is Representation, meaning the same resource can be represented in different formats, i.e. JSON, XML, HTML, etc. Thankfully, Spring provides several view implementations and views resolvers to render data as JSON, XML, and HTML.
 
 Similar to the @ResponseBody annotation, which is used for converting the response to the format client wants (by using HttpMessageConverts), Spring MVC also provides @RequestBody annotation, which uses HttpMethodConverter implementations to convert inbound HTTP data into Java objects passed into a controller's handler method.

  The Spring framework also provides a template class, RestTemplate, which is similar to  JdbcTemplate, and  JmsTemplate, which can consume REST resources.

JAX-RS API implementation in RESTful Web Services

Java API for RESTful Web Services (JAX-RS) is a Java programming language API spec that provides support in creating web services according to the Representational State Transfer (REST) architectural pattern. JAX-RS uses annotations, introduced in Java SE 5, to simplify the development and deployment of web service clients and endpoints.

Difference between SOAP and RESTful Web Services

 Message Oriented Communication vs Resource Oriented Communication.

Message Oriented Communication is a way of communicating between processes. Messages, which correspond to events, are the basic units of data delivered. And it is classified message-oriented communication according to two factors---synchronous or asynchronous communication, and transient or persistent communication.

Resource Oriented Communication  is the structural design supporting the inter-networking of resources. A resource, in this context, is any entity that can be identified and assigned a uniform resource identifier (URI).