article

Representational State Transfer (REST) is a software architectural style for distributed hypermedia systems like the world wide web. The term originated in a 2000 doctoral dissertation about the web written by Roy Fielding, one of the principal authors of the HTTP protocol specification, and has quickly passed into widespread use in the networking community.

While REST originally referred to a collection of architectural principles (described below), people now often use the term in a looser sense to describe any simple web-based interface that uses XML and HTTP without the extra abstractions of MEP-based approaches like the web services SOAP protocol. It is possible to design web service systems in accordance with Fielding's REST architectural style, and it is also possible to design simple XML+HTTP interfaces in accordance with the RPC style but without actually using SOAP. These two different uses of the term REST cause some confusion in technical discussions, even though RPC is not an example of REST.

Systems that follow Fielding's REST principles are often referred to as RESTful; REST's most zealous advocates call themselves RESTafarians.

Principles

REST's proponents argue that the web has enjoyed the scalability and growth that it has as a result of a few key design principles:

  • A stateless client/server protocol: each HTTP message contains all the information necessary to understand the request. As a result, neither the client nor the server needs to remember any communication-state between messages. In practice, however, many HTTP-based applications use cookies and other devices to maintain session state (some of those practices, like URL-rewriting, are not RESTful).
  • A set of well-defined operations that apply to all pieces of information (called resources): HTTP itself defines a small set of operations, the most important of which are POST, GET, PUT and DELETE. People often compare these with the CRUD operations required for data persistence, though POST does not fit cleanly into the comparison.
  • A universal syntax for resource-identification: in a RESTful system, every resource is uniquely addressable through the resource's URI.
  • The use of hypermedia both for application information and application state-transitions: representations in a REST system are typically HTML or XML files that contain both information and links to other resources; as a result, it is often possible to navigate from one REST resource to many others, simply by following links, without requiring the use of registries or other additional infrastructure. It's purely XML based.

Resources

An important concept in REST is the existence of resources (pieces of information), each of which can be referred to using a global identifier (a URI). In order to manipulate these resources, components of the network (clients and servers) communicate via a standardized interface (HTTP) and exchange representations of these resources (the actual files uploaded and downloaded) – it is a matter of debate, however, whether the distinction between resources and their representations is too Platonic for practical use on the web, though it is popular in the RDF community.

Any number of connectors (e.g., clients, servers, caches, tunnels, etc.) can mediate the request, but each does so without "seeing past" its own request (referred to as "layering", another constraint of REST and a common principle in many other parts of information and networking architecture). Thus an application can interact with a resource by knowing two things: the identifier of the resource, and the action required – it does not need to know whether there are caches, proxies, gateways, firewalls, tunnels, or anything else between it and the server actually holding the information. The application does, however, need to understand the format of the information (representation) returned, which is typically an HTML or XML document of some kind, although it may be an image or any other content.

REST versus RPC

A REST web application requires a different design approach than an RPC (Remote procedure call) application. In RPC, the emphasis is on the diversity of protocol operations, or verbs; for example, an RPC application might define operations such as the following:

getUser() addUser() removeUser() updateUser() getLocation() addLocation() removeLocation() updateLocation() listUsers() listLocations() findLocation() findUser()

With REST, on the other hand, the emphasis is on the diversity of resources, or nouns; for example, a REST application might define the following two resource types

User {} Location {}

Each resource would have its own identifier, such as http://www.example.org/locations/us/ny/new_york_city. Clients work with those resources through the standard HTTP operations, such as GET to download a copy of the resource, PUT to upload a changed copy, or DELETE to remove all representations of that resource. Note how each object has its own URL and can easily be cached, copied, and bookmarked. POST is generally used for actions with side-effects, such as placing a purchase order, or adding some data to a collection.

For example, the record for a User might look like this:

<user> <name>Jane User</name> <gender>female</gender> <location href="http://www.example.org/locations/us/ny/new_york_city" >New York City, NY, US</location> </user>

To update the user's location, a REST client could first download the above XML record using HTTP GET. The client would then modify the file to change the location, then upload it again using HTTP PUT.

Note, however, that the HTTP verbs do not provide any standard method for resource discovery -- there is no HTTP LIST or FIND operation, to correspond with the list*() and find*() operations in the RPC example above. Instead, REST data applications work around the problem by treating a collection or set of search results as another type of resource, requiring application designers to know additional URLs or URL patterns for listing or searching each type of resource.

For example, an HTTP GET request on the URL http://www.example.org/locations/us/ny/ might return a list of links to an XML file for each location in New York, while an HTTP GET request for the URL http://www.example.org/users?surname=Michaels might return a list of links to all users with the surname "Michaels".

REST provides some guidance on how to perform this kind of action as part of its "hypermedia as the engine of application state" constraint, which suggests the use of a forms language (such as HTML forms) for specifying parameterized queries.

The OpenSearch initiative from A9.com attempts to standardize searches using REST by establishing specifications for discovery of and generic format for use with REST based systems including RDF, XTM, Atom, RSS (in its various flavours), and Plain Old XML (POX) with XLink to handle links.

Public implementations

Since REST is defined very broadly, it is possible to claim an enormous number of RESTful applications on the web (just about everything accessible through an HTTP GET request). Taken more narrowly, in its sense as an alternative to both Web services generally and the RPC style specifically, REST can be found in several areas on the public web:

There are likely many other similar offerings.

Note also that many of the above may not be perfectly RESTful, that is, they may not respect all of REST's architectural constraints. However, they are all inspired by REST, and respect the most architecturally significant of those constraints, in particular the uniform interface constraint. Those services have been called "Accidentally RESTful".

See also

External links

Software architecture

REST | Representational State Transfer | REST | REST

 

This article is licensed under the GNU Free Documentation License. It uses material from the "Representational State Transfer".

Home Page • arts • business • computers • games • health • hospitals • home • kids & teens • news • physicians • recreation• reference • regional • science • shopping • society • sports • world