You are looking at documentation for an older release. Not what you want? See the current release documentation.
Representational State Transfer (REST) is a style of software architecture for distributed hypermedia systems, such as World Wide Web. The term was introduced in the doctoral dissertation in 2000 by Roy Fielding, one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification, and has come into widespread use in the networking community.
REST strictly refers to a collection of network architecture principles that outline how resources are defined and addressed. The term is often used in a looser sense to describe any simple interface that transmits domain-specific data over HTTP without an additional messaging layer, such as SOAP or session tracking via HTTP cookies.
The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.
REST uses a resource identifier to identify the particular resource involved in an interaction between components. REST connectors provide a generic interface for accessing and manipulating the value set of a resource, regardless of how the membership function is defined or the type of software that is handling the request. URL or URN are the examples of a resource identifier.
REST components perform actions with a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components. A representation is a sequence of bytes, plus representation metadata to describe those bytes. Other commonly used but less precise names for a representation include: document, file, and HTTP message entity, instance, or variant. A representation consists of data, metadata describing the data, and, on occasion, metadata to describe the metadata (usually for the purpose of verifying message integrity). Metadata are in the form of name-value pairs, where the name corresponds to a standard that defines the value's structure and semantics. The data format of a representation is known as a media type.
|Data Element||Modern Web Examples|
|resource||the intended conceptual target of a hypertext reference|
|resource identifier||URL, URN|
|representation||HTML document, JPEG image|
|representation metadata||media type, last-modified time|
|resource metadata||source link, alternates, vary|
|control data||if-modified-since, cache-control|
REST uses various connector types to encapsulate the activities of accessing resources and transferring resource representations. The connectors present an abstract interface for component communication, enhancing simplicity by providing a complete separation of concepts and hiding the underlying implementation of resources and communication mechanisms.
|Connector||Modern Web Examples|
|server||libwww, Apache API, NSAPI|
|cache||browser cache, Akamai cache network|
|resolver||bind (DNS lookup library)|
|tunnel||SOCKS, SSL after HTTP CONNECT|
The primary connector types are client and server. The essential difference between the two is that a client initiates communication by making a request, whereas a server listens to connections and responds to requests to supply access to its services. A component may include both client and server connectors.
An important part of RESTful architecture is a well-defined interface to communicate. In particular, it is a set of HTTP methods, such as POST, GET, PUT and DELETE. These methods are often compared with the CREATE, READ, UPDATE, DELETE (CRUD) operations associated with database technologies. An analogy can also be made:
PUT is analogous to CREATE or PASTE OVER,
GET to READ or COPY,
POST to UPDATE or PASTE AFTER, and
DELETE to DELETE or CUT.
The RESTful architecture is not limited to those methods, one good example of extension is the WebDAV protocol.
The CRUD (Create, Read, Update and Delete) verbs are designed to operate with atomic data within context of a database transaction. REST is designed around the atomic transfer of a more complex state and can be viewed as a mechanism for transferring structured information from one application to another.
HTTP separates notions of a web server and a web browser. This allows the implementation of each to vary from the other based on the client/server principle. When being used RESTfully, HTTP is stateless. Each message contains all information necessary to understand the request.
As a result, neither the client nor the server needs to remember any communication-state between messages. Any state retained by the server must be modeled as a resource.
You should read Oracle Documentation for more knowledge about REST.