Handling Status Codes with an HTTP Object
| HTTP status codes have a dual purpose: They are not only useful in the back end for development purposes, but they are also very useful on the front end for providing users with the status of their interactions. As we briefly covered in Chapter 2, "The Request", the request status of the Ajax object is equivalent to the HTTP status of the file that is being requested. HTTP status codes represent the response from the server based on the status of the file that is being requested. The codes are broken up into five categories, which cover all the possible responses that a server could return to an HTTP request. The HTTP status code categories are listed next; the xx after each number represents other digits which exist in each category and are used to specify a type of error.
In order to handle these status codes and provide meaningful user feedback, we will create an HTTP object. The object that we will be creating will take the request status from the Ajax object, which will be a number from 1 to 4. It will then return the status code that corresponds with that number value as a string that will contain an explanation of what occurred on the server side. Providing this level of detail is essential when creating web applications because a user should always understand what is happening and what, if anything, went wrong. The HTTP object is fairly simple, but it is quite large because of the level of detail it covers. The following is a condensed version of the object and the methods it contains: HTTP = {}; HTTP.status = function(_status){} HTTP.getInformationalStatus = function(_status){} HTTP.getSuccessfulStatus = function(_status){} HTTP.getRedirectionStatus = function(_status){} HTTP.getClientErrorStatus = function(_status){} HTTP.getServerErrorStatus = function(_status){}The HTTP object has been separated into different methods for each response category. To make this object more usable, there is a status method that is used as the access point to the object. All status calls are filtered through this method to the corresponding category to which they belong. Each method takes the status that is passed as a parameter and returns a string response that we, as the developers, choose to respond with. As you will see, the current object has default responses, which represent the literal status code titles, but these can and should ultimately be changed to responses that are more informative and user friendly. Let's take a look at the status method in Listing 9.10 to get an idea of how this method handles delegating the status number value to the corresponding method category. Listing 9.10. Delegating HTTP Status Codes to the Correct Methods (HTTP.js)
The status code categories are split into different numbers. When the status method receives the _status parameter, it takes the first number from the parameter and locates the corresponding method based on its category number. For example, if the object received a 404 status code value, it would use the first number in the code, which would be the number 4, to locate the appropriate method category and delegate it to that method. In order to use the first number in the status code, we need to convert the number to a string and split it into an array of strings. After we have created the array, we can target its first item, which is the item in the 0 position, and perform a switch on it to match it with the corresponding method category. HTTP Status Code CategoriesThe five method categories that the HTTP object consists of correspond to the HTTP status code definition categories. Each of the methods in the object takes a _status parameter, which is used to return the corresponding message. This section will cover the status codes that are handled by each method, but will not go into detail about each status code definition. As a useful reference, I have also added the URL in each method to the status code definition categories, which are defined in detail on the W3C website. The first method that we will focus on, which can be viewed in Listing 9.11, corresponds to the Informational category. Listing 9.11. Handling Informational Status Codes (HTTP.js)
The getInformationalStatus method handles all the informational status codes for the HTTP object. The informational status code category consists of two status codes:
The second method, named getSuccessfulStatus (see Listing 9.12), handles all the successful HTTP status codes. Listing 9.12. Handling Successful Status Codes (HTTP.js)
The successful status code category consists of six status codes:
The third status code method category is the getredirectionStatus (see Listing 9.13) method. Listing 9.13. Handling Redirection Status Codes (HTTP.js)
The getredirectionStatus method handles all the redirection status codes for the HTTP object. The redirection status code category consists of seven status codes:
The fourth method for handling status codes is the getClientErrorStatus (see Listing 9.14) method. Listing 9.14. Handling Client Error Status Codes (HTTP.js)
The getClientErrorStatus method handles all the client error status codes for the HTTP object. This status category is intended to present statuses based on an error that occurs from an interaction that a client makes. The client error status code category is the largest of the five categories, consisting of seventeen status codes:
The fifth and final status code category method is named getServerStatus (see Listing 9.15), which consists of all the server error status codes that could be returned from an HTTP request. The difference between the client and the server status code categories is instead of responding with errors based on client interactions, the server status codes are relative to the server and its inability to perform a request. Listing 9.15. Handling Redirection Status Codes (HTTP.js)
The server error status code category consists of five status codes:
As you can see, the HTTP object is fairly simple, yet it is fairly large as well due to the fact that it handles every single status code that an HTTP request could possibly return. This object will save a lot of coding time; all that you must do for your applications is provide a custom message or even an action based on the code. Using the HTTP ObjectAdding the HTTP object to the Ajax engine is extremely simple after the JavaScript file has been imported into the current document. We will need to call only a single method, which will provide the status feedback as a string. Listing 9.16 shows how to return the status to the Ajax requestor. Listing 9.16. Returning the HTTP Status As a String (Ajax.js)
Now that we have the HTTP object created, we can begin to return meaningful status codes to requesting objects as feedback to the user or we can use these status codes to provide the user with other options. For instance, let's say that we have an application that is attached to a shopping cart and we receive a 402: Payment Required response from the server. We could either redirect the user to a payment page or dynamically write a payment form to the page through DHTML. Another possibility could be a 401: Unauthorized response, which we could handle by redirecting the user to a login page or, again, we could use DHTML to present a form to the user for login/registration without refreshing the page. When the user logs in or registers, we could send the request through Ajax. After we receive a successful response, we could present the user with the original data she was requesting. There is a huge difference between providing the user with feedback versus providing her with options. When we provide a user with feedback, she does not have any options and is usually left wondering what to do next. If we provide the user with options, we make the process much more intuitive and allow the user to progress on her own without worrying about reading cryptic messages from the server side. In fact, those cryptic messages also take time for developers to write. Rather, developers could be planning their next response to provide the user with a new option. HTTP status codes are just one of the features that make Ajax so powerful, yet they are very seldom a topic of conversation. If you think of the example situations in this context, you can accomplish some fairly complex user interaction scenarios that will dynamically occur based on your users' interactions after your project has been completed. It will become a living application that reacts based on the current users' status and interactions. |
EAN: 2147483647
Pages: 129