Web Application Architecture in 2008 and Beyond

Application Architecture 2008: The More Things Change the More they Stay the Same
This post is about the future of Web Application Architecture in 2008 and beyond. It details some trends in "returning to the basics" regarding the adoption of REST-based services that are happening right now that I believe will lead to companies being able to build solid long-term platforms for service integration and collaboration with external partners and end-users alike.

Back to the Basics, Son
A good architecture should minimize the degree of difficulty for end-users, software components, and external vendors and third-party software to use a system. It should maximize the opportunity for the same people and software to derive value from and contribute value to the system.

The way the existing World Wide Web works, with the simple HTTP protocol and URI standards, provides a good model that companies like Yahoo, Amazon, Google, and Microsoft (as of late) are capitalizing on to build long-term scalability and integration with disparate systems. The architecture of the web is called Representational State Transfer (REST), a term coined by the principal author of the HTTP and URI specifications, Roy Thomas Fielding .

Prerequisite Reading
To fully appreciate this post, I recommend you read a little more about the history of REST and WWW architecture as well as how they compare and contrast to SOAP / RPC models for Web Services and Service Oriented Architecture.


To summarize what you will find in the background reading, here is what REST boils down. Note that I am applying the example HTTP here because HTTP is an example of a REST-based architectural style.

• HTTP focuses on finding named resources through the global addressing scheme afforded by the URI standard
• HTTP allows applications to GET, PUT, POST, and DELETE to those URIs.
• GET retrieves a representation of an resource located at a specific URI
  
• PUT attempts to replace the resource at the given URI with a new copy
  
• REST is not a "buzzword" or a "fad". It is a description of how the WWW actually operates and how it has scaled to the size and success that it has thus far.

Addressability and Uniform Interface are the Keys to Success

As explained in the Wikipedia entry, and alluded to above, addressability and the uniform interface are two of the most crucial features for a REST-based architecture.

I want to compare HTTP's implementation of a REST based architecture with a similar example of SQL.

In HTTP, we have the standard verbs, or methods, GET, POST, PUT, and DELETE.

Similarly, in SQL, we have SELECT, INSERT, UPDATE, DELETE.

Imagine a web site with the following URL:

http://www.mysite.com/Items/ViewItem.aspx?id=123

Here, we have several parts:

http://www.mysite.com = Host address

/Items = Subdirectory off the root

/ViewItem.aspx?id=123 = This breaks down into several parts:

View = verb (action)
Item = noun (resource)
id = parameter name
123 = parameter value

The actual HTTP request for this would look something like:

GET /ViewItem.aspx?id=123

Now, consider an alternative URL:

http://www.mysite.com/Items/123

Here we still have the first two parts the same, but we roll up all the others into the /123. This makes sense because we already have a verb, it's GET. We already know we are looking at the "Items" subdirectory, so that identifies the type of noun that we want already.

Detailed Example of Exposing and Consuming Data

Let's take the example a little further with microformats.

http://www.mysite.com/Items/123




Background Reading

These are some links for understanding Web (REST) architecture.

Real World Business Point of View

• Mark Nottingham (principal architect at Yahoo) discussing how Yahoo uses REST-based principles for integrating all of their properties: http://www.infoq.com/presentations/services-without-soap-yahoo
  

Quick technical review

• Overview of REST: http://en.wikipedia.org/wiki/Representational_State_Transfer
• Paul Prescod on the REST vs. SOAP debate: http://www.prescod.net/rest/rest_vs_soap_overview/
  

Technical In-Depth analysis

• Pete Lacey on InfoQ about REST and WS-*: http://www.infoq.com/interviews/pete-lacey-rest
  
• My recent book review of RESTful Web Services: http://joshuagough.blogspot.com/2008/02/book-review-restful-web-services.html
• Other recent interviews with architects on InfoQ: http://www.infoq.com/rest/
• Steve Jones' post "Want to be cool? Learn REST. Want a career? Learn WS": http://service-architecture.blogspot.com/2006/11/want-to-be-cool-learn-rest-want-career.html
  

Detailed understanding

• Roy Fielding's Ph.D. dissertation that introduced the term, "Architectural Styles and the Design of Network-Based Software Architectures": http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
• RESTful Web Services book from O'Reilly: http://www.oreilly.com/catalog/9780596529260/
  

Miscellaneous
These are just some miscellaneous notes.

The more things change the more they stay the same
During the early years of the web we had a few building blocks:

• HTTP (GET, POST, PUT, DELETE)
  
• URI (http://www.hostname.com/resource)
• HTML (and friends like the blink and marquee tags)
• User agents (Netscape, Mosaic, Lynx, MSIE)
• CGI and PERL
  

Later, we had things like:

• Cascading Style Sheets
• XML
  
• Java
• Javascript

A little later than that we got:

• PHP
• .NET
• SOAP based Web Services
• XmlHttpRequest
  

Most recently, we've seen:

• Python popularity growth
• Ruby
• Ruby on Rails with ActiveRecord
• Asynchronous Javascript and XML (AJAX)

Things that will never happen

My grandfather Gene Gough worked at IBM for 35 years as a programmer and manager. He sent out a funny email the other day. I don't know if this list is accurate or not, but here is the list posted on line: http://www.rense.com/general81/dw.htm.

Here are three good ones from the list

"Louis Pasteur's theory of germs is ridiculous fiction." -- Pierre Pachet, Professor of Physiology at Toulouse, 1872

"I think there is a world market for maybe five computers." --Thomas Watson, chairman of IBM, 1943

"There is no reason anyone would want a computer in their home." -- Ken Olson, president, chairman, founder of Digital Equipment Corp. 1977.

I worked with the people at CDC's Epi-X (http://www.cdc.gov/epix) program in the past, and I think they'd strongly disagree not just the first one, but with all three.

We are all familiar with the now famous "Technology Adoption Curve", which looks like a standard bell curve. You can read more about this here: http://en.wikipedia.org/wiki/Diffusion_of_innovations