Representational State Transfer

One of the alternatives to the conventional web-services stack is REST, an acronym for Representational State Transfer, a term coined by Roy Fielding in his PhD dissertation to describe the architectural style of the World Wide Web [Fielding, 2000]. Fielding, one of the principal writers of the HTTP specification and a co-founder of the Apache Group, defines the term as follows:

Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use [2000].

Fielding and Taylor explain the advantages of such a system:

"REST is a coordinated set of architectural constraints that attempts to minimize latency and network communication, while at the same time maximizing the independence and scalability of component implementations. This is achieved by placing constraints on

connector semantics, where other styles have focused on component semantics" [Fielding and Taylor, 2002].

This approach uses mechanisms for message transmission that pre-date web services: XML, HTTP and URIs (Uniform Resource Indicators), as may be seen in Figure 5-1. One of the early problems with SOAP in the minds of many XML developers, particularly at the W3C, lay in the fact that version 1.1 did not permit the use of HTTP GET, choosing POST instead, regardless of the fact that GET is both less dangerous in its side-effects, and cacheable. This has been remedied in SOAP 1.2, as has the exposure of the URIs in the HTTP headers (they had been concealed in SOAP 1.1). SOAP 1.2 recommends that, where practical, particularly when using the HTTP binding, separate resources are identified by separate URIs, so that SOAP endpoints fit into the web architecture in the same way as other web accessible resources. This has the added

advantage that SOAP resources are now suitable for use with the HTTP GET method instead of being tied to HTTP POST (see Section 4.1 of Mitra, 2003).

HTTP packet

Figure 5-1: REST Web-Service Structure [Hinchcliffe, 2005]

SOAP 1.2 narrowed the gap, at least between SOAP and REST. Zur Muehlen, Nickerson and Swenson take the changes in SOAP 1.2 to mean that "SOAP can be used, but used in such a way that it does not violate REST principles" [2004] The escalation both in complexity and in the number of specification releases since SOAP 1.2 has, however, prompted individuals such as Bosworth (cited on page 104) to question the current nature of web services. Companies such as

Amazon have actively developed REST-based interfaces for their clients as alternatives to those based on SOAP.

Barr, of Amazon.com, explained in an interview that: "we put up both the SOAP and the REST or XML-over-HTTP interface and the experience so far has been that the REST interface is definitely in the lead. Probably close to 80% of the calls we process are REST-style calls" [Barr, 2003]. Its popularity he attributed to its simplicity: "…people go towards the simplest solution."

He did share his belief, however, that SOAP interfaces might become more popular as web-service transactions became more complex.

REST with its basis in the URI is particularly well suited for operations requiring browser access. REST is excellent for simpler operations but where features such as transaction processing and authentication are required, SOAP may still have an edge. Fortunately, there does not have to be a situation in which only SOAP or only REST is chosen. Each may be seen to have complementary uses. Zur Muehlen, Nickerson and Swenson characterize the difference between them in terms not of technology but of style: "REST.. represent[s] a navigational style of design, and .. SOAP.. represent[s] a procedural style [2004].

Another enthusiast for REST is Butterfield, the CEO of Flickr³², a new, different and very popular tag-based, photo-sharing program exposed as a web service. When asked in an

interview published on the O'Reilly Network whether Flickr was a next-generation web service, Butterfield replied:

On the strictly practical side, I think we had one person inquire about using the SOAP version of the API. I don't know if any apps were actually built. There is at least one application built on XML-RPC. But all the others – I don't even know how many there are – are built on the REST API. It's just so easy to develop that way; I think it's foolish to do anything else [Butterfield, 2005].

As with Amazon, the user interface is web-based and therefore particularly suited to a REST style.

32 See http://www.flickr.com/.

In March of 2005, Yahoo decided to expose its services through a REST interface, explaining that "REST based services are easy to understand and accessible from most modern

programming languages… We believe REST has a lower barrier to entry, is easier to use than SOAP, and is entirely sufficient for these services" [Yahoo, 2005]. In July of 2005, Safari Books Online, a venture shared by O'Reilly Media Inc. and The Pearson Technology Group, joined Yahoo, Amazon and Flickr by publishing their web service also through a REST interface, which now enables users to browse not only bibliographic details but also a book's contents, giving limited access to the text in much the same way that Google Print now offers.

What companies as successful as Amazon and Flickr have to say about the popularity of their REST interfaces is particularly interesting in the light of the conflict that arose in the W3C TAG [Technical Architecture Group] when supporters of SOAP-based web services like Manes ridiculed REST as a purely academic pursuit:

W3C is, at heart, an academic organization. And its perfectly reasonable for W3C to pursue its academic goals (REST and the Semantic Web). But if W3C wants to play a major role in business systems, and if W3C wants to continue receiving funding from the big software vendors, then the W3C TAG must be willing to [accommodate] the

requirements of big business. If the REST faction continues to try to undermine the existing Web services architecture, it will alienate big business [Manes, 2002].

Fielding's response to this posting is as pointed as it is obviously angry, not only in its rebuttal of the idea of REST as a purely academic pursuit but in its placing of SOAP in the context of failed distributed-object architectures:

The only reason SOAP remains in the W3C for standardization is because all of the other forums either rejected the concept out of hand or refused to rubber-stamp a poor

implementation of a bad idea. If this thing is going to be called Web Services, then I insist that it actually have something to do with the Web. If not, I'd rather have the WS-I group responsible for abusing the marketplace with yet another CORBA/DCOM than have the W3C waste its effort pandering to the whims of marketing consultants [Fielding, 2002].

5.3 Advantages of REST over Conventional Web Services