What is REST? As we have mentioned previously, it is an architectural style derived from the Web architecture. More specifically, it is a style derived from constraints applied to elements within the Web Architecture. This derived style is eventually defined with more concreteness in the form of fundamental constraints on components, connectors and data. In order to steer away from too much theory, we will first list and explain the five constraints Fielding thinks are important to the Web Architecture and then fully describe the three main classes of components that comprise the essence of REST. Fielding looked at the evolved Web and noted five basic properties: (a) Client, Server, (b) Client, Stateless-Server, (c) Client-Cache, Stateless-Server, (d) Uniform-Client-Cache, Uniform-Stateless- Server, and (e) Layered-Uniform-Client-Cache, Layered-Uniform- Stateless-Server. There is also a sixth optional property called code-on-demand but it is not important for the explanation given here. These constraints are no doubt confusing, but many of the terms used here have entered the everyday technical vernacular. What did Fielding really mean by each of these constraints? Table 1 provides an explanation of each constraint.
It is important to note that the constraints Fielding describes, which are shown in Table 1, are descriptive of the Web at the time (circa 2000). He tries here to capture the essence of what made the Web successful in the form of abstract constraints rather than pay homage to one set of standards or vendor technologies. This being said, there is an underlying tribute to HTTP in his abstract architectural style. Once he has laid out the constraints of the Web, he derives Representational State Transfer as a new set of constraints over three fundamental artifacts: data elements, connectors and components. We believe that the most important part of REST, its subtle core, can be found in how the data component is described. The next section describes these components, with special attention given to the data elements.
In the context of traditional client-server interaction, such as an HTTP GET, data is transferred from client to server. In REST terms, a resource is de-referenced and its representation transfers from the server to the client. The important observation that Fielding made (and it now seems obvious) is that links are static and can represent an invariant concept, while the representation can change over time. This idea consists in the demarcation between resource and representation. While this sounds lofty, it is exactly the same idea used when a Web site publishes a link, such as the "latest" schedule for some fictional meeting such as "http://www.foobar.com/schedule.html." We can note that there are three concepts tied to this: (a) The resource ("the latest schedule") which is ostensibly invariant, (b) the link identifier ("http://www.foobar.com/schedule.html"), and finally (c) the actual schedule or document returned when the link is de-referenced-the representation. Fielding notes that any information that can be named can be a resource. The resource identifier term is used to describe the URI, but it could also have been a URN as well. So why is this resource concept important? Resources provide some familiar features such as interface decoupling as well as generality for the resource. That is, the resource can be manifested in more than one way; resources can realize one or more representations based on more specific client and server interactions, and these representations can be negotiated during the communication itself.
The second part of the data elements of REST includes the all important representation. This is where the term state transfer comes into use; Fielding looks at the Web like a giant state machine and the state transitions are initiated by and stored on the clients themselves (as the servers are stateless). Further, the next state of this giant state machine is considered to be captured in the representations of resources that transfer from server to client. This further implies that clients initiate state transitions of the Web in response to new state options that come back as server responses. It is at this point that we can begin to understand how the term Representational State Transfer (REST) becomes appropriate.
But what are representations? Representations consist of the data itself, metadata to describe it, as well as additional (optional) metadata to describe the metadata. In order to avoid getting lost a jungle of theory again, the reader can understand this simply as a message payload, a content-type, and possibly security information or routing information that is applied to the message or payload. Again, this is all still abstract, but Fielding's original thesis suggests HTTP as the model to be followed. Figure 2 shows a pictorial representation of the central concepts of resource and representation, and how they map to technology choices such as HTTP or even XML.
Figure 2 shows three examples: A, B and C. In each example, a client is making a request to a server for the representation of a resource. Example A shows the representation in the abstract, the way Fielding conceived it. Example B shows the concrete implementation of HTTP with a content type to describe the payload. Finally, Example C shows another way of fitting into Fielding's framework with the use of an XML payload and an XSD, or schema definition, for the complete metadata. You should note that the last example is sometimes referred to as POX, or Plain Old XML.
The final two architectural pieces of REST are the connectors and components. These are less interesting because most of what makes REST important for our discussion is encapsulated in the data views just described. Connectors are the interfaces used by components. Fielding describes these as simply as client, server, cache, revolver, and tunnel. The first two are self explanatory. The third is a client-side browser cache or a web cache, the fourth is a DNS lookup library and the fifth is a tunneling protocol such as SOCKS or SSL/TLS. Each of these components has interfaces with "in" and "out" parameters. The "in" parameters consist of request control data, a resource identifier, and representation. The "out" parameters consist of response control data, resource metadata, and representation. The four components that utilize these connectors are the origin server, gateway, proxy and useragent. Fielding notes further that some components can play a dual role as client and server (such as a proxy) and terms these components intermediaries within the architecture.
As noted previously, the Fielding dissertation and the definition of REST appears benign-it does not throw down any overt challenge to SOAP, nor does it appear to be solving the same problem as SOA or even SOAP. In fact, the REST architectural style appears to be a description of essential elements of the Web. If this is the case, what is the nature of this debate? Now that we have some of the theory behind us we must probe further and examine not what REST is, but what REST has become; or rather, the meme it has transformed into.