R is for... REST
REST stands for Representational State Transfer, an acronym coined by Dr. Roy Fielding in 2000 as part of his doctoral dissertation at the University of California, Irvine.
As Dr. Fielding states in Chapter 6,
Since 1994, the REST architectural style has been used to guide the design and development of the architecture for the modern Web.
REST is technically a formalization of his approach to building distributed network architectures, with the World Wide Web being the canonical example of its application. Today, however, REST is often positioned as an alternative technology to SOAP (Simple Object Access Protocol) for the implementation of web services. To that end:
REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.
Section 5.1.5
Identification of Resources
A REST approach to services treats everything on the web as a resource, and every resource has a name – its Uniform Resource Identifier (or URI). A SOAP-based approach, in contrast, is operation-centric where the focus is on using the URI essentially as a method call, with parameters provided on the query string, as form variables, or perhaps in an encoded message body.
For sake of example, let’s look at Amazon’s Simple Storage Service (S3). The service provides functionality to store arbitrary objects in the cloud, by assigning them to ‘buckets’ created within the storage account (similar to a one level directory/file structure). So, your resource in this case can easily be expressed as a URI, such as
https://s3.amazonaws.com/mybucket/myobject
This URI, if provided in browser client for instance, will result in retrieving that particular resource (by virtue of the default GET action, which we’ll get to shortly).
Contrast that with a SOAP approach, which would be routed to a common URL:
https://s3.amazonaws.com/soap
and require a payload SOAP message similar to
<GetObject xmlns="https://doc.s3.amazonaws.com/2006-03-01">
<Bucket>mybucket</Bucket>
<Key>myobject</Key>
<GetMetadata>true</GetMetadata>
<GetData>true</GetData>
<InlineData>true</InlineData>
<AWSAccessKeyId>1D9FVRAYCP1VJEXAMPLE=</AWSAccessKeyId>
<Timestamp>2009-05-01T12:00:00.183Z</Timestamp>
<Signature>Iuyz3d3P0aTou39dzbqaEXAMPLE=</Signature>
</GetObject>
The contrast in approaches here is rather apparent. In REST, the object or resource you’re addressing is immediately discoverable, whereas in a SOAP approach, the URI tells you next to nothing, and you have to parse the XML message payload to determine both what you want to do (GetObject) and to what you want to do it (<Bucket> and <Key>).
Manipulation of Resources through Representations
The representation of a resource indicates the specific sequence of bytes that describes that resource. A resource's representation isn’t absolute and can be driven by information sent in the message that acts upon the resource. The ability to provide alternative representations provides a nimbleness that allows the resource to be treated in a format most conducive to the application at hand.
For instance, in the implementation of ADO.NET Data Services, a REST-based technology in .NET 3.5 SP1 for exposing data models over the web, two representations can be returned for a given resource depending on the Accept: HTTP header passed in the request:
- The default format is Atom Publishing Protocol (AtomPub)
- The alternative format, JavaScript Object Notation (JSON), can be engaged by setting the
Acceptheader’s value toapplication/json
The default format provides integration with other applications that support the AtomPub format and also with rich client applications, such as Silverlight, that interface with Data Services. That format, however, isn’t as efficient when accessing services from within an AJAX-based client, and that’s where JSON comes in, providing a more compact format that can be quickly serialized for manipulation in the browser’s document object model (DOM).
Self-descriptive messages
In terms of RESTful services, the message transport is generally HTTP, a protocol that includes a number of operations that can be applied to the resource specified in the URI. Most implementations support the use of the following HTTP verbs to provide manipulation of the resource:
| GET | Retrieve a resource representation |
| POST | Create a new resource based on representation provided in the HTTP message |
| PUT | Update a resource given the representation provided in the HTTP message |
| DELETE | Delete the resource |
Conveniently, these operations correspond to the CRUD (Create-Read-Update-Delete) operations that are part of most data-centric applications. It’s this simple HTTP verb + URI approach for data access and manipulation that has propelled REST based services to become the mechanism of choice for simple data access in distributed applications.
Hypermedia as the engine of application state
The protocol of the web, HTTP, is at its core stateless, which has made life difficult for developers trying to build applications. Concepts such as cookies, ViewState in ASP.NET, and storing information in databases have all been used to overlay a sense of statefulness on the web.
REST has a goal “to improve server scalability by eliminating any need for the server to maintain an awareness of the client state beyond the current request.” A direct result of this is that the representation returned from a RESTful request must contain the entire state of the application at that point. That includes not only data, but also the enumeration of what you can do next in the application.
For example, consider a shopping cart application on which you’ve just done a search for an item. Such applications often make use of a cookie to tie the session to the stateful shopping cart for that user maintained on the server. Strictly speaking, this breaks the RESTful paradigm, since the state of the application is not wholly described by the current page – it takes the cookie value to provide the connection between this set of search results and the current user. If the page included a hidden field, for instance, that provides an ID for the user’s cart (which itself would be considered a resource in the REST paradigm), then the RESTful constraint would be met.
Read more about it
There are numerous on-line resources and books that cover REST topics, including a few relatively recent ones that address REST in the specific domain of .NET technologies. Here’s a sampling that you may want to add to your library
In terms of technology implementations, here’s a few that make heavy use of RESTful approaches