WebServices dot org

Web Services: REST in Peace?

Introduction

Over the course of the last few years there has been a great deal of debate and even open conflict in the domain of Web Services architecture between the Web Services orthodoxy and the REST community. While this conflict was most public in the somewhat ill-fated W3C Web Services architecture group, advocates from across the spectrum of Web Services thinking have fought and argued through blogs and discussion forums across the net.

At the heart of this increasingly heated debate is the architectural preference of each side and potentially at stake the future shape and form of Web Services. The crux of the argument that the REST community levels at contemporary Web Services is that they are in the process of defining APIs for each service, and thus are doomed to recreate a kind of angle-bracketed CORBA on the Web where each service API has to be understood and individually integrated into an application. This fact, along with the well-known difficulties in scaling such tightly-coupled systems, leads the REST camp to maintain that Web Services will not be able to support Web-scale applications.

This is an accusation which is profoundly unfair, since Web Services best practices have moved on since the early days when, in all fairness, Web Services was little more than an XML encoding for RPC. However times have changed and best practice in today?s Web Services environment bears little resemblance to how things used to be.

This article presents the case that the REST and orthodox positions have not only converged, but that the so-called orthodoxy has actually surpassed the REST architectural principles by decoupling the Web from Web Services and reducing the REST approach to a subset of the new Web Services architecture.

The RESTifarian Jihad

While the REST architectural style has been developed since 1996, it came to real prominence in the year 2000 from a Ph.D. thesis by Roy Fielding as part of a broader project on hypermedia being run at the University of California, Irvine. The REST architecture is in effect a distillation of the architecture of the World Wide Web, drawing out those characteristics which have allowed the growth of the largest and most scalable distributed application that the world has known to-date.

While early discussions of REST in the Web Services community tended to be dismissive and focus on the human-oriented nature of the Web, the REST architecture is not specifically about browsers and Web pages, but about permitting software systems which have been developed in isolation (such as Web browsers and Web servers) to communicate. In modern Web Services parlance, we would call this loose coupling.

More formally, the REST architecture hinges on a uniform API for transferring the state of identifiable resources between programs, based on the HTTP verbs. Whereas in the World Wide Web those resources would typically be HTML documents, there is no inherent restriction on the kinds of documents that resources can be transferred and it is a minor leap of intuition to see that machine-readable documents could just as easily be transferred.

Thus a RESTful application centres on the transfer of structured XML documents between services using the uniform interface provided by HTTP. The benefit of a REST approach is that the semantics of the interface are ?inherited? from the semantics of the Web and, so REST proponents would argue, such uniformity makes large-scale integration of disparate components straightforward as it has in the domain of the WWW.

Under the constraints of a RESTful system architecture, a combination of message content plus HTTP verb gives an operation its semantics. Typically performing GET on a given URI is a safe and idempotent operation which returns the state of the identified resource at a given moment as an XML document. Conversely POSTing to a specific URI with a XML payload updates the state of the identified resource. There are similar Web-derived semantics for PUT and DELETE, though these are less often utilised.

The drawback of this solution is that a service's resources are publicly known and any changes to the public resource representations have to be masked to consumers or applications will break. Furthermore, REST relies on RESTful protocols (those protocols that were designed to conform to REST?s constraints) like HTTP. However, some protocols (such as SMTP) which were not designed according to RESTs constraints may be used after a limited fashion.

The Machine-Readable Crusade

Perhaps the most vociferous criticism that the REST community has levelled at the orthodox Web Services approach is that it is too RPC oriented ? effectively building a CORBA-like infrastructure over SOAP. While it might be appealing to view the combination of SOAP and WSDL as equivalents of IIOP and IDL, this is an extremely outdated view of best practice in Web Services and misses much of how Web Services have evolved.

In fact, the current architectural trend in Web Services is, like REST, to use message-passing as the basis of composing services into applications. This categorically does not mean just using document/literal SOAP, though document/literal is a sensible way to format SOAP messages. It means that services do not communicate by invoking operations on each other (even with document/literal style SOAP being used to transport the invocations), but focus solely on the exchange of messages between services. The advancement from the early days of Web Services to current best practice is shown in Figure 1.

Unlike the REST model, however, there is no assumption that services possess protocol-specific uniform interfaces, nor is there the assumption that the means of message transfer necessarily implies particular semantics. Where in the REST view, using GET indicates an idempotent read-only request, and POST indicates an update there are no such semantics attached to the movement of messages in the orthodox Web Services model. Nor is there any assumption that the resource representations that the service uses are publicly known, indeed it is good Web Services practice for the reverse to be true.

In addition, where the transfer mechanism for REST-based applications is HTTP (or similar) and couples the message content with the transfer protocol, the transfer mechanism for Web Services-based applications is simply SOAP. The mechanisms that propagate messages between services are considered to be transport protocols even if in reality they are application protocols like SMTP or network transport protocols like TCP.

Furthermore, the semantics of a message exchange are derived solely from the message content and is only resolved within the scope of the application within which the message exchanges take place ? the means of moving message between services does not impact the semantics whatsoever.

To help conceptualise these ideas and bridge the gap between the two communities, some Web Services proponents have argued that all Web Services implicitly have a single logical operation (which may be considered an extreme form of a uniform interface) at the same network level where the REST model advocates the HTTP verbs. This operation, sometimes called ?processThis? or ?processMessage? is an imaginary construct (it does not exist in code or contract) whose semantics are similar to the HTTP POST verb in REST insofar as it moves a message from sender to receiver but crucially can be bound to any underlying transport protocol and does not imply anything about the effect of message receipt (i.e. messages transported this way may or may not cause actions that are safe and idempotent). These styles are contrasted, along with the RPC-style Web Services, in following table.

The inclusion of an imaginary or logical operation allows us to bind Web Services to practically any underlying network protocol (including application protocols like HTTP, SMTP, and JMS) to transport SOAP messages between services, depending on the quality of service requirements of the application. It is undeniably simpler than the REST interface and far more generic since it can be bound to arbitrary transports not just those with HTTP-like characteristics. Furthermore the loose-coupling that REST systems achieve is not jeopardised under this regime.

Of course the format of those messages that a service is prepared to receive (and indeed respond with) must be known in advance before a service can be composed into an application. This is where WSDL comes into play. WSDL describes the messages that a service understands, the message exchange patterns that the service supports, and the protocol bindings and physical endpoints where that service is deployed (see Figure 2).

While the WSDL keywords are a legacy from the old days of when SOAP was a meaningful acronym and Web Services were mostly used as a platform-independent RPC mechanism, the concepts can easily be recast into message-oriented terms. For instance, operation elements can simply be seen as message exchanges, and portType elements (or interfaces from WSDL 2.0) are just groups of logically related message exchanges.

The Emperor Really Does Have New Clothes

The advantages of conceptualising an application in terms of services and messages, rather than in terms of APIs (either RESTful or RPC oriented varieties) are clear: it enables super-loose coupling both for composing services into applications and in the implementation of a service itself.

From the point of view of a consumer, binding directly to a Web Service, increases the danger that we begin to view services as objects. This is a mistake ? treating the exchange of messages with a service as being equivalent to a local object invocation is inherently incorrect. However, if our implementations bind to the messages that a service exchanges, we are always bound to local objects (in fact the objectified versions of the messages) and can treat them as such without danger. Additionally, since crossing service boundaries is made explicit by the sending of messages, it reinforces the fact, in architecture and code alike, that inter-component communications is between remote, autonomous entities.

From the point of view of a service implementer, the fact that the messaging layer effectively decouples the service logic from the network means that the service implementation can evolve easily since changes at that level are not seen by any consumers. Thus the implementation is able to evolve without breaking applications that consume the service.

Considering the Web Services architecture from a holistic perspective, the message-oriented Web Services model decouples service implementations, messages, and transports. Such loose-coupling implies that applications should be less brittle and more resilient to service maintenance and evolution since there is no directly binding to components across service boundaries.

Summary

The Web Services practices of today bear little resemblance to the practices of yesteryear. Fundamental to the architecture of Web Services applications today is the ability to design in terms of message-passing, which is a paradigm that enables loose coupling, and thus supports the construction of scalable and robust distributed applications.

While there has been some degree of convergence with the message-oriented approach advocated by the REST community, the Web Services model has evolved further than the REST model (and much further some of its advocates like to admit) and is at a point where it is decoupled from the architecture of the Web and the dogma that accompanies it. While the Web Services community has much to thank the REST community for in terms the insight they brought to the discussion, the fact is that Web Services ? at least in more enlightened quarters - are now on the right track.

Acknowledgements

Thanks to Savas Parastatidis ( http://savas.parastatidis.name ) and Mark Baker ( http://markbaker.ca ) for helpful feedback during the preparation of this article.