Reducing Server Load and Network Traffic in REST/Ajax Architectures

It is always enjoyable for me when I find solutions that effectively utilize the simple, foundational tools that our software infrastructure is built on. Instead of building yet more layers of complexity on top of existing layers of complexity, we find ways to solve the problem with the core constructs of the software architecture stack. I think that those moments of serendipity are why architectural styles like RESTful and POJO programming models resonate so much with developers. There is a short article on developerWorks which shows us how to reduce network traffic and server processing for Ajax/REST architectures, but the real jewel here is the way they effectively use the HTTP 304 status code instead of recommending more complicated solutions. The article starts by setting the context for some of the challenges for Ajax/REST architectures:

A simple fact about HTTP is both its greatest strength and its central weakness: HTTP is a stateless protocol. Each request to an HTTP server resource is meant to be idempotent, which is to say the same request should return the same result at each invocation. Idempotency is the central idea in REST: the same request — perhaps encoding client information — should return the same data whenever it is made. ... [But] understanding the meaning of "same data" is more subtle than it might appear. Only in caricature must the same URI always return identical data. After all, even a static Web page might change when the content is corrected (say, the typos are fixed in a published article). The idea behind idempotency is merely that the change involved should not be a direct effect of the GET request itself. So having a constantly changing resource like this is a perfectly reasonable approach:

http://myserver.example.com/latest_data/

The issue is merely that what makes up "latest_data" depends on something other than merely whether, when, and by whom this data has been retrieved. A server can be perfectly RESTful and still reflect "the state of the world."

The problem they are trying to solve, then, is two-fold: reduce network traffic and reduce server processing for repetitive requests. That is certainly not a new problem. The way they go about tackling the server processing part of the problem is predictable: caching. One of the benefits of a RESTful architecture is its ability to be cached. But that only solves the server processing problem; you are still sending the full dataset over the network for every request even if nothing changes. And that is where the HTTP 304 status code comes in:

The "Not Modified" problem is, in fact, addressed right in the HTTP protocol, though this correct solution is underused. What we may — and should — do is simply return an HTTP 304 status code. It is the responsibility of our Ajax code to check for 304 status, and if found, simply not to change client application state based on the (absence of) data sent from the poll.

They were even nice enough to provide some code examples, including what the Javascript making the Ajax call and correctly handling the 304 response would look like:

var r = new XMLHttpRequest();
r.onreadystatechange=function() {
    if (r.readyState==4) {
        if (r.status==200) {  // "OK status"
            displayData(r.responseText);
        }
        else if (r.status==304) {
            // "Not Modified": No change to display
        }
        else {
            alertProblem(r);
        }
    }
}
r.open("GET",'http://myserver.example.com/latest_data/',true)
r.send(null);