Losing REST over Ajax Errors?

All too frequently, I see Ajax examples where the response is handled like this: (pseudo-code used for demonstration purposes)

xhr.onreadystatechange = function() 
{
  if ( xhr.readyState == 4 )
  {
    if (xhr.status == 200) 
    {
      // Process returned data (eg: Parse XML).
      
      // Check status of result depending on custom/ad-hoc error detection.
      //  -- most commonly a 0 for fail, or 1 for pass
      
      // Deal with/report error, or take some other action based upon returned data.
    }
  }
}

The above approach works, but as your application grows and your need to provide useful error reporting (and error avoidance!) increases, the good ol’ boolean-style error checking will quickly become unwieldy. I can see it now…

1. Developer 1: What does an error code of 7 mean again?
2. Developer 2: Ummm, Hang on, I’m sure we wrote that down somewhere…

Fear not, there’s a much smarter alternative, one which you rely upon every time you load up your browser—HTTP Status Codes (check out Mark Pilgrim’s humourous abridged list if the thought of reading yet another RFC sends you into an glazed-eyed stupor).

Taking the previous example, I’ve added a switch block for some of the status codes that will be most useful in handling the response to your JavaScript HTTP request:

xhr.onreadystatechange = function() 
{
  if ( xhr.readyState == 4 )
  {
    switch ( xhr.status )
    {
      case 200: // OK!
        /* 
         * If the request was to create a new resource 
         * (such as post an item to the database)
         * You could instead return a status code of '201 Created'
         */  
      break;
      
      case 304: // Not Modified
        /* 
         * This would be used when your Ajax widget is 
         * checking for updated content,
         * such as the Twitter interface.
         */   
      break;
      
      case 400: // Bad Request  
        /* 
         * A bit like a safety net for requests by your JS interface
         * that aren't supported on the server.
         * "Your browser made a request that the server cannot understand"
         */
      break;
      
      case 409: // Conflict 
        /* 
         * Perhaps your JavaScript request attempted to 
         * update a Database record 
         * but failed due to a conflict 
         * (eg: a field that must be unique)
         */
      break;
      
      case 503: // Service Unavailable
        /* 
         * A resource that this request relies upon
         * is currently unavailable 
         * (eg: a file is locked by another process)
         */
      break;    
    }
  }
}

So the next time you’re about to stick <status>1</status> or similar into an XML response, take a deeper look into HTTP Status Codes. It might be the first step towards getting some REST, which is most certainly a Good Thing™.

Related posts:

1. Illustrations: What HTTP Errors Look Like What do HTTP errors look like? Cartoonist and illustrator Adam...
2. Boundaries vs. Barriers: 3 Ways to Set Limits without Losing Work We all need to create boundaries in our work, but...
3. Rest In Peace – Your Online Legacy Will Continue Legacy Locker Co-Founder Jeremy Toeman describes the service as an...
4. Are You Violating the Eolas Ajax Patent? It's true: Eolas has an Ajax patent and is filing...

This entry was posted on Wednesday, April 4th, 2007 at 10:17 am, contains 858 words, 6 images, and is filed under JavaScript & CSS. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed. The views and opinions in this blog post are those of its author.