RepresentationalStateTransfer is the architectural style of the WorldWideWeb, as defined by the primary architect of HTTP 1.1 and co-author of the URI specification, RoyFielding.  The term was coined in 2000 in his Ph.D dissertation ''Architectural Styles and the Design of Network-based Software Architectures'' (http://www.ics.uci.edu/~fielding/pubs/dissertation/top).  It serves as a significant reference in the work being done by the W3C Technical Architecture Group (TAG) (see http://www.w3.org/2001/tag/).

The style is a composition of two architectural styles
	* Layered, code-on-demand, client-cached-stateless server (itself a composition)
	* Uniform interface

It is the uniform interface that is the differentiator of this style.  The uniform interface implies that all connectors within the system must conform to this interface's constraints.  The four REST interface constraints are:
	* identification of resources
	* manipulation of resources through representations
	* self-descriptive messages
	* hypermedia as the engine of application state.

In practical terms, on the WorldWideWeb, these constraints are embodied as:
	* URIs
	* HTTP request & responses
	* HTTP headers with MIME types
	* URIs embedded in a media type (which are in turn, potentially dereferencable via HTTP)

The benefits of REST are demonstrated by the properties that are induced by these constraints, such as:
	* ''network effects'' due to ubiquitous resource identification and uniform operation semantics
	* ''visibility'' of system interaction through self-description & uniform operation semantics
	* ''scalability'' through layering, representation caching, and stateless interaction
	* ''simplicity'' through self-description, uniform operation semantics, and layering
	* ''better user perceived performance'' through caching and code on demand (e.g. AjaxWebApplications) 
	* ''evolvability'' through layering, statelessness, and uniform operation semantics, which enable a wide variety of media types & processing implementations to flourish

----


REST is a guideline for evolving an architecture to highten the above properties, with the tradeoff that it is not appropriate for all forms of architectural interaction.  An example may be where fine-grained precision is valued over interoperability, or when non-uniform message exchange patterns are required to meet latency goals.  

Having said this, and noting that while HTTP 1.1 only has a small number of operations, REST does not imply we should stop there.  There is a place for a larger number of methods, so long as the semantics of these methods are uniform across all connectors that support them.  SIP, the SessionInitiationProtocol, for example, exhibits many aspects of REST, in providing a uniform interface for negotiating multi-party sessions.	It arguably could/should have been an HTTP extension instead of a separate protocol.

----
To quote from the Rest Wiki:

"The REST hypothesis is that the semantics of HTTP constitutes a coordination language which is is sufficiently general and complete to encompass any desired computational communication pattern. I.e., the hypothesis is that GET / PUT / POST / etc. can provide all coordination semantics between discretely modeled units of programs (and in case it's not all, or there's other practical reasons for it, HTTP is sufficiently extensible to support new methods being added). REST is comparable to message passing (provably completely general) or function calling with parameters in its ability to express any computational communication / coordination pattern. Obviously, there are other operations needed to actually do the work."

One interesting aspect of REST vs. these new XML-based web services is how REST jives with the InterfaceSegregationPrinciple -- that interfaces are defined by the client's needs, not the server's needs... and for dependency management we need smaller, fewer protocols -- not more.

Their Wiki is here: http://rest.blueoxen.net/

----
See Roger Costello's excellent summary at http://www.xfront.com/REST-Web-Services.html

See Also: SoapRpcBreaksRest RestArchitectureDiscussion

CategoryCommunicationProtocol