Rest Architectural Style

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 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: In practical terms, on the WorldWideWeb, these constraints are embodied as: The benefits of REST are demonstrated by the properties that are induced by these constraints, such as:

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

EditText of this page (last edited June 17, 2009) or FindPage with title or text search