As I wrote earlier I had the pleasure to read this very well written post over at IBM about why Ajax is a way to be RESTful. Bill Higgins starts by explaining what REST is and why it is important:

REST’s “client-stateless-server” constraint forbids session state on the server. Designing within this constraint promotes the system properties of visibility, reliability, and scalability. But immersive server-side Web applications wish to provide a great deal of personalization to a single user [...]

In short the REST-style allows us to keep simple resources that can be cached, and therefore take the load away from the server. Back in March I wrote a post explaining why Ajax is a better concept than traditional, session-driven, applications. It allows you to map a resource (the data that is needed by your application) to an URI, this allows you to keep those information-fragments well separated from the rest of the application, which will change its state during execution, while data probably wont. The “pure” data is separated from its representation and has become cacheable, and REST compatible, or as Bill explains it,

Going back to the Amazon.com example, imagine that you click a link to view information about a book on design patterns. In Amazon.com’s current application, the link click action sends a variety of information identifying the requested resource. It also sends various session-state artifacts that let the server create a new page that includes prior session state (such as recently viewed items), personalization information (such as “you purchased this book in 1999″), and the actual business resource itself. The application is very dynamic and highly personalized — but not cacheable and not natural scalable (though as Amazon demonstrates, these architectural problems can be overcome with millions of dollars of infrastructure engineering). Now consider this action in the (imaginary) Ajax version of the application. No processing needs to occur with regard to “recently viewed items.” This is simply information already present in the page that won’t go away when you click on a link. Two requests will likely be related to the design patterns book:

• /Books/0201633612 (where 0201633612 is the design pattern book’s ISBN number)
• /PurchaseHistory/0201633612/bhiggins@us.ibm.com

The first hypothetical request returns information about the book (author, title, descriptions, and so on); it contains no user-specific data. The absence of user-specific data means that as more users request the same resource, it is likely that they’ll retrieve cached versions of it from intermediate nodes on the Internet rather than from the originating server. This characteristic reduces server and overall network load. The second request, on the other hand, contains user-specific information (Bill Higgins’ purchase history for this book). Because this data includes personalized information, only a single user should ever successfully retrieve and cache the data from this URI. Although this personalized data doesn’t have the scalable characteristics of the nonpersonalized data, the important point is that this information is retrieved from a distinct URL and therefore has the positive characteristic that it doesn’t interfere with the caching of other application and data resources that are cacheable.

Personally I hope that this style of archieving things will be common practise in future. It makes things a lot easier, and solves many of the scalability problems we currently have

Technorati Tags: ajax, REST