“… and Now You Know the REST of the Story …”

When I first read Roy Fielding’s 2000 Ph.D. thesis a few months back, Architectural Styles and the Design of Network-based Software Architectures, which coined the REpresentational State Transfer (REST) acronym, I was mostly trying to understand what I dimly perceived as one side in an argument between the WS* brand of Web services crowd and a passionate group of “simpler” HTTP-oriented advocates. (Tim Bray’s 2004 piece helps draw the distinction, mostly related to complexity, but also the use of messaging and states with resulting server dependencies.) I found Fielding’s thesis to be very interesting and historically informative about the standards development in the early Web (yes, I read the whole thing), but it was also frankly above my sophistication level and pay grade at the time.

I’ve come to learn much more about these differences and debates in the intervening months. Recently, one of the best sources I’ve discovered that explicates the RESTful approach in a way I find very understandable and approachable is Bill Higgins’ two-part Ajax and REST series on IBM’s developerWorks.

In Part I, Advantages of the Ajax/REST Architectural Style for Immersive Web Applications, Bill talks about the evolution to “immersive” Web applications and how by slipping into server-side architectural dependencies reliablity and scalability are compromised. He also talks about dynamic content and its particular challenges to cacheability and performance. He notes how highly interactive (“immersive”) applications practically forced a server-side approach during the Web’s early development, but that Ajax now allows the return to more stateless server-side and scalable architectures.

“The fact that Ajax lets you interact with a server without a full refresh puts the option of a stateful client back on the table. This has profound implications for the architectural possibilities for dynamic immersive Web applications: Because application resource and data resource binding is shifted to the client side, these applications can enjoy the best of both worlds — the dynamic, personalized user experience we expect of immersive Web applications and the simple, scalable architecture we expect from RESTful applications.”

And, of course, screen refreshes are also reduced, improving the user’s experience. As someone directly responsible for how a very large, individualized app moved in the direction of server-side dominance, these observations loudly resonate.

In Part II, Meeting the Challenges of Ajax Software Development, Bill goes on to discuss how to evaluate and, if warranted, adopt Ajax-style development within organizations that have traditionally used server-side Web applications. His logical recommendations to move forward include starting small, use frameworks and use tools. He perhaps most importantly observes that new team members may need to be recruited, since RESTful mindsets, technologies, architectures and paradigms differ from traditional enterprise development.

Thus, both of Higgin’s articles address the questions of network efficiencies raised by Fielding in his thesis (p. 32):

“An interesting observation about network-based applications is that the best application performance is obtained by not using the network. This essentially means that the most efficient architectural styles for a network-based application are those that can effectively minimize use of the network when it is possible to do so, through reuse of prior interactions (caching), reduction of the frequency of network interactions in relation to user actions (replicated data and disconnected operation), or by removing the need for some interactions by moving the processing of data closer to the source of the data (mobile code [or Ajax!; comment added]).”

One criticism of Ajax is the need to account for various browser differences and incompatibilities. While these differences are real, they are also narrowing and, in any case, still pose differences even for relatively simple HTML or CSS rendering independent of Ajax. I also believe it can be argued that some of the more prominent Javascript libraries such as Dojo or Prototype are themselves doing much to smooth over browser differences. It seems to me that since good Web-wide design already calls for attention to cross-browser differences, that the increase in scalability and resilience occasioned by RESTful designs warrants moving in that direction.

The more fundamental point is whether time to market and development time can co-exist with a start-small, incrementalist approach. Another problem with traditional enterprise development is that the languages and their IDEs and supporting infrastructure have not been designed from the ground up to support RESTful designs and architectures. Ruby on Rails, for example, may be a far superior choice, but it is difficult for existing incumbents with market share to junk their prior investments. One option for existing Java shops could be to carefully re-factor the existing code base and segregate out the Web interaction layer to use JRuby.

As Fielding succinctly states: “Semantics are a by-product of the act of assigning resource identifiers and populating those resources with representations.” Like the mediations of representational states within the Web itself, the interoperability of the semantic Web lends itself to simple conceptual design (though, of course, potentially complex implementation).

(BTW, because of this Higgin’s series I went back and re-read Fielding’s thesis. I now can certainly appreciate more of the arguments. I suspect the Fielding document is one of those that has insights and a mindset that warrant frequent re-reading in the years to come, esp. Chapters 5 and 6. For example, it has really aided my better understanding of the relation to the Rails CRUD approach and its mapping to the HTTP and SQL verbs, or the wider adoption of Javascript v. Java for embedded Web apps.)