11.1 Defining REST

REST stands for Representational State Transfer, a term coined by Roy Fielding in his doctoral dissertation. (Check it out at http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.)The author introduces the REST architectural style, developed as an abstract model of the web architecture to guide the redesign and definition of the HTTP and URIs.

REST encompasses a simple philosophy for modeling problem domains: "give a URI to everything that can be manipulated by a limited set of operations and let the client software determine the usage metaphor." This pattern is ubiquitous: a small number of methods applied to diverse kinds of data.

The main questions that motivated the development of the REST architectural style were: how to introduce a new set of functionality to an architecture that is already widely deployed and how to ensure that its introduction doesn't adversely impact, or even destroy, the architectural properties that have enabled the Web to succeed. This chapter discusses one possible answer to that question. Some examples will be provided, although the main focus of the discussion is on architecture and design of applications in accordance with REST's principles; examples are added purely for illustrative purposes and will provide you some guidelines.

11.1.1 The Scientific Definition

If you aren't comfortable with definitions derived from Ph.D. dissertations, you can skip this section (it will be kept short).

The REST style is an abstraction of the architectural elements within a distributed system. The key aspects of REST are the nature and state of data elements (compare this approach to the distributed object style, in which the key aspect is the encapsulation of all data within the processing components ). REST identifies six data elements: a resource, resource identifier, resource metadata, representation, representation metadata, and control data, shown in Table 11-1.

Table 11-1. REST data elements

Data element	Examples
Resource	The intended conceptual target; "the home page of the O'Reilly web site," "the latest version of the SOAP::Lite toolkit"
resource identifier	Name , URI; http://soaplite.com/download/SOAP-Lite-latest.zip
resource metadata	Vary
Representation	Sequence of bytes, HTML document, archive document, image document
representation metadata	Last-Modified , media type; text/xml
control data	If-Modified-Since , If-Match

The key abstraction of information in REST is a resource . Any information that can be named can be a resource: a document, a home page of a weblog, or a search result. A resource is a conceptual object that has identity, state, and behavior. A resource identifier (in the form of a URI) identifies the particular resource that might be observable via its representations . A representation (for example, a web page or a document) is something that you get from a resource and not the resource itself. Some resources are static; their representations don't change. When queried, they always correspond to the same sequence of bytes. Other resources are dynamic: their value changes over time, but the semantics stay the same. The semantics are unique (one concept, one identity) and distinguish one resource from another.

Representation metadata describes the representation and resource metadata describes the resource. Control data defines the purpose of a message between components, such as the action being requested . If the value set of a resource consists of multiple representations, content negotiation may be used to select the appropriate representation depending on the message control data.

11.1.2 The Practical Definition

The Web is full of resources that are named by URLs and have different representations. For example, CPAN (the Comprehensive Perl Archive Network) defines a resource that may be described as "Distribution of SOAP::Lite module v0.55." Clients may access this resource using this URL:

http://search.cpan.org/author/KULCHENKO/SOAP-Lite-0.55/

A representation of the resource is returned. This might be a HTML page that provides information about the module. This representation places the client application in a state (another representation, for example a XML document, may place the client in a different state). The client traverses the returned representation and accesses another resource using a link in the document:

http://search.cpan.org/src/KULCHENKO/SOAP-Lite-0.55/Changes

The client application changes the state based on the returned representation. As a result, the transfer of state occurs with each resource representation; hence Representational State Transfer.

REST is an architecture style that separates a server's implementation from a client's perception of resources. It enables transfer of data in streams of unlimited size and type, supports intermediaries as data transformation and caching components, and concentrates the application state within the user agent components. It leverages HTTP and the URI namespace for all types of applications and allows for independent evolution of clients, servers, and intermediaries. In the future it may allow accessing individual data objects as resources.

Figure 11-1 gives a summary of REST in one diagram.

Figure 11-1. REST definition

All these services that have been used in past years ”search engines (Google), book ordering services (Amazon), CPAN ”are services created according to REST principles.