FW: 1 page REST summary

My summary of Roy's REST chapters, now on a public list.

-----Original Message-----
From: 'Roy T. Fielding' [mailto:fielding@apache.org]
Sent: Monday, March 11, 2002 7:49 AM
To: tag@w3.org
Cc: David Orchard
Subject: 1 page REST summary


This is mostly Dave's work of compressing my REST chapters into a one
page summary.  I've made a few minor changes, right now, but I think it
will require major edits before being readable by someone unfamiliar
with the topic.

Note that this is still different from what I think should be one of
the major sections of the arch document, which would be more of a
discussion of just "Application State using Hypertext".

....Roy

REST
----

REST (Representational State Transfer) is an architecture style that
approximates the World-Wide Web.  REST provides a set of architectural
constraints that, when applied as a whole, emphasizes scalability of
component interactions, generality of interfaces, independent deployment of
components, and intermediary components to reduce interaction latency,
enforce security, and encapsulate legacy systems.  REST consists of a set of
constraints, or invarients, that are chosen for the properties they induce
on the target architecture, in this case the Web.

The REST constraints are:
- Client/Server, the separation of rendering concerns from the data model
and control logic concerns
- Stateless, that each request from client to server contains all the
necessary data for a server to understand the request.
- Caching, that resources are labelled as cachable or not, and intermediary
nodes between the client and server can respond on behalf of a server with
the cached data.
- Uniform Interface, the consistent constraints on interface between
components, specifically resource identification, resource manipulation
through representations, self-describing messages, and messages as the
embodiment of application state.
- Layering, the encapsulation of each component so that components "know"
only about the components they are interacting with.
- optional Code-on-demand, the ability for clients software to download and
execute code, such as Java Applets, ActiveX controls, scripts, XSLT.

REST focuses on the roles of components, the constraints upon their
interaction with other components, and their interpretation of significant
data elements.  REST ignores the details of component implementation and
protocol syntax.  REST components communicate by transferring a
representation of a resource in a format matching one of an evolving set of
standard data types, selected dynamically based on the capabilities or
desires of the recipient and the nature of the resource. Whether the
representation is in the same format as the raw source, or is derived from
the source, remains hidden behind the interface.

Typical hypertext systems support one of three possible styles
of data representation: 1) render the data where it is located and send a
fixed-format image to the recipient; 2) encapsulate the data with a
rendering engine and send both to the recipient; or, 3) send the raw data to
the recipient along with metadata that describes the data type, so that the
recipient can choose their own rendering engine.  The Web provides a hybrid
of all three options by focusing on a shared understanding of data types
with metadata, but limiting the scope of what is revealed to a standardized
interface.

The key abstraction of information in the Web is a resource. Any information
that can be named can be a resource.   The Web uses a resource identifier to
identify the particular resource involved in an interaction between
components.  The Web relies on the author choosing a resource identifier
that best fits the nature of the concept being identified.

Web components perform actions on a resource by using a representation to
capture the current or intended state of that resource and transferring that
representation between components.  A representation consists of data,
metadata describing the data, and, on occasion, metadata to describe the
metadata.  Response messages may include both representation metadata and
resource metadata.  The data format of a representation is known as a media
type. A representation can be included in a message and processed by the
recipient according to the control data of the message and the nature of the
media type

Web components perform various roles in interactions.  User agents,
gateways, proxies, and origin servers are the main roles that a component
can act in.  A component may act in different roles depending upon the
interaction.

Received on Monday, 26 August 2002 16:27:41 UTC