What is REST and when to use it

In software engineering, the term software architectural stylegenerally refers to "a set of design rules that identify the kinds ofcomponents and connectors that may be used to compose a system orsubsystem."*Some common examples of architectural styles include the Pipe andFilter, Layered, Push Based, and so on. In the web services world,REpresentational State Transfer (REST)is a key design idiom that embraces a stateless client-serverarchitecture in which the web services are viewed as resources and canbe identified by their URLs. Web service clients that want to use theseresources access a particular representation by transferringapplication content using a small globally defined set of remotemethods that describe the action to be performed on the resource. RESTis an analytical description of the existing web architecture, and thusthe interplay between the style and the underlying HTTP protocolappears seamless.
The HTTP methods such as GET and POST arethe verbs that the developer can use to describe the necessary create,read, update, and delete (CRUD) actions to be performed. Some may seean analogy to operations in SQL, which also relies on a few commonverbs, as shown in Table 1. However, the REST style and HTTP protocolare mutually exclusive, and REST does not require HTTP.
Table 1: Relationships Between SQL and HTTP Verbs
Action
SQL
HTTP

Create
Insert
PUT
Read
Select
GET
Update
Update
POST
Delete
Delete
DELETE

When to Use REST

Architects and developers need to decide when this particular styleis an appropriate choice for their applications. A RESTFul design maybe appropriate when
The web services are completely stateless. A good test is to consider whether the interaction can survive a restart of the server.
A caching infrastructure can be leveraged for performance. If the data that the web service returns is not dynamically generated and can be cached, then the caching infrastructure that web servers and other intermediaries inherently provide can be leveraged to improve performance. However, the developer must take care because such caches are limited to the HTTP GET method for most servers.
The service producer and service consumer have a mutual understanding of the context and content being passed along. Because there is no formal way to describe the web services interface, both parties must agree out of band on the schemas that describe the data being exchanged and on ways to process it meaningfully. In the real world, most commercial applications that expose services as RESTful implementations also distribute so-called value-added toolkits that describe the interfaces to developers in popular programming languages.
Bandwidth is particularly important and needs to be limited. REST is particularly useful for limited-profile devices such as PDAs and mobile phones, for which the overhead of headers and additional layers of SOAP elements on the XML payload must be restricted.
Web service delivery or aggregation into existing web sites can be enabled easily with a RESTful style. Developers can use technologies such asAsynchronous JavaScript with XML ((Ajax)) and toolkits such asDirect Web Remoting (DWR) to consume the services in their web applications. Rather than starting from scratch, services can be exposed with XML and consumed by HTML pages without significantly refactoring the existing web site architecture. Existing developers will be more productive because they are adding to something they are already familiar with, rather than having to start from scratch with new technology.
A SOAP-based design may be appropriate when
A formal contract must be established to describe the interface that the web service offers. The Web Services Description Language (WSDL) describes the details such as messages, operations, bindings, and location of the web service.
The architecture must address complex nonfunctional requirements. Many web services specifications address such requirements and establish a common vocabulary for them. Examples include Transactions, Security, Addressing, Trust, Coordination, and so on. Most real-world applications go beyond simple CRUD operations and require contextual information and conversational state to be maintained. With the RESTful approach, developers must build this plumbing into the application layer themselves.
The architecture needs to handle asynchronous processing and invocation. In such cases, the infrastructure provided by standards such asWSRM and APIs such asJAX-WS with their client-side asynchronous invocation support can be leveraged out of the box.