REST Roundup
May 8, 2002
The XML-Deviant this week takes a brief look back over the REST debate, to see what's been learned, and what's still to be done.
Let a Thousand Threads Bloom
The so-called REST versus SOAP discussion looks like it's going to be a serious contender for this year's "Debate that Spawned a Thousand Threads" award. The fact that this web architecture debate has migrated across so many forums is a testament to both the tenacity of the two camps and to the popularity of the Google SOAP API which has reignited the discussion.
Rather than take on the daunting task of attempting to summarize this entire debate, I wanted to devote this week's column to picking out several points which I believe are important and that might potentially have gotten lost in the exhausting and often heated conversation.
Architecture
In general one very positive outcome of the discussion is that it has highlighted the importance of architecture: the value in defining the architectural properties of a system and its processing model. Architecture has been undervalued of late, particularly with the advent of agile methodologies, a point which Martin Fowler addresses in his " Is Design Dead?" article.
One critique of REST is that it's seen as retrofitting an architecture onto a system, the Web, which has been grown rather than designed. REST has therefore been viewed as revisionist. Yet this is something that Fowler seems to consider a strength, noting that early architectural decisions "aren't expected to be set in stone". Re-evaluating early decisions, particularly with a view to simplification is a good strategy -- whether the current web architecture as currently implemented is simple is another question, but certainly the REST architecture described in Roy Fielding's dissertation is elegant and can be used to inform future developments.
Fowler's suggestion, "to begin by assessing what the likely architecture is...", is an approach that web services activity should consider. If the architecture is the web, then does REST apply? If not, then it should be clear where the boundaries and the resulting trade-offs are. Happily this seems to be happening. Fowler's advice to "be ready to simplify your architecture as soon as you see that part of the architecture isn't adding anything" is also pertinent: where is the real value in web services technology? SOAP? WSDL? Or allowing systems to emerge from data combined from many sources by publishing plain XML?
The discussion has certainly provided both sides with a better understanding of the other's goals, and the TAG is steadily evolving some guidelines out of this. The draft findings on when to use GET have been updated: not giving a resource a URI is defined to be non-optimal but is not prohibited. And David Orchard is leading the activity to define a GET binding for SOAP services. This will provide a useful bridge between the two architectures -- one that developers have already discovered, as Jon Udell has pointed out.
Ease of Use
A clear advantage of web services in their present state is the effort that's been expended to make their construction as easy as possible. The .NET development environments seem to exemplify this point-and-click style of development. While it's wrong to attempt to hide the network, there's nothing to wrong with providing tools to limit the pain as far as possible.
REST is an architecture, rather than a toolkit, so it would be wrong to criticize it for failing to integrate with IDEs seamlessly. But it's pretty clear that there's room for development of a set of tools to ease the development of RESTful applications. These toolkits might follow a similar paradigm to the J2EE architecture, offering containers in which resources can be managed, and APIs to flexibly generate representations from those resources which are bound to URIs and HTTP requests.
Apache Cocoon already offers a useful array of functionality in this space. The concept of a "sitemap" binds processing pipelines to HTTP requests, with the pipeline inputs being any mixture of static and dynamic resources. As the sitemap and pipeline definitions are themselves XML documents, one can imagine a suite of tools to allow point-and-click creation of services using Cocoon components.
The interesting aspect to the ease of use argument in favor of web services is that it's WSDL and not SOAP which allows the complexity to be hidden. During a recent exchange on XML-DEV, Francis Norton commented that "[i]ncreasingly I feel that more of the value of Web Services will come from WSDL than from SOAP." A number of other developers have expressed similar opinions.
So there's a possibility that some of the ease of use benefits of web services could still be delivered, without SOAP. Paul Prescod has already pointed out some of the limitations of WSDL as an IDL for HTTP based services, offering his own WRDL as an alternative. WSDL is not yet a W3C Recommendation so there's still time for a set of functionality that includes all types of web service to be specified. RESTful toolkits will surely require support for this kind of interface.
Ease of Understanding
|
|
|
Also in XML-Deviant |
|
One area that still needs attention is in communicating the subtleties of RESTful application design. The RESTWiki, rest-discuss mailing list and Paul Prescod's recent articles on XML.com have certainly helped, but there's clearly a zen of REST which must be achieved to successfully design REST-style applications. But not everyone has the time available to undertake a monastic study of the relevant RFCs to help achieve this blessed state.
Good REST design is about more than using the right HTTP methods and possibly even more than simply assigning everything a URI. A nice example of this can be extracted from an exchange between Prescod and Francis Norton on XML-DEV. In this exchange, Norton was looking for feedback on how best to structure an HTTP-based query for a train timetable application. Prescod's answer, "there is no query", is appropriately Zen-like, but illustrates the point that good REST design principles are good hypertext design principles -- a point which hasn't really been stressed in the REST debates.
While this fact is implicit in the architectural principles, it can clearly guide design of an application and more effectively allow its data to be combined with and reused by other services, one of theclear goal of web services in general. Prescod's "Extreme Web Services" guidelines could serve the basis for a more detailed discussion of these design decisions, ideally something which couches these principles as design patterns: a form which developers seem very happy to take on board, and which would allow convergence with other attempts to define information system architectures.