JavaServer Faces

HTTP

The Hypertext Transport Protocol (HTTP) is the lingua franca of the web. In order to develop any type of web application, you must understand at least the basics of this protocol. Before we dig into servlets and JSP, let’s see what HTTP is all about.

HTTP is based on a very simple communications model. Here’s how it works: a client, typically a web browser, sends a request for a resource to a server, and the server sends back a response corresponding to the resource (or a response with an error message if it can’t process the request for some reason). A resource can be a number of things, such as a simple HTML file returned verbatim to the browser or a program that generates the response dynamically. The request/response model is illustrated in Figure 4-1.

Figure 4-1. HTTP request/response with two resources

This simple model implies three important facts you must be aware of:

• HTTP is a stateless protocol; the server doesn’t keep any information about the client after it sends its response, and therefore can’t recognize that multiple requests from the same client may be related.

• Web applications can’t easily provide the kind of immediate feedback typically found in standalone GUI applications, such as word processors or traditional client/server applications. Every interaction between the client and the server requires a request/response exchange. Performing a request/response exchange when a user selects an item in a list box or fills out a form element is usually too taxing on the bandwidth available to most Internet users.

• There’s nothing in the protocol that tells the server how a request is made; consequently, the server can’t distinguish between various methods of triggering the request on the client. For example, the server can’t differentiate between an explicit request caused by clicking a link or submitting a form and an implicit request caused by resizing the browser window or using the browser’s Back button. In addition, HTTP doesn’t provide any means for the server to invoke client specific functions, such as going back in the browser history list or sending the response to a certain frame. Also, the server can’t detect when the user closes the browser.

Over the years, people have developed various tricks to overcome HTTP’s stateless nature—the first problem. JSF uses these tricks behind the scenes, so you rarely need to worry about it, but we’ll look at how it’s done later. The other two problems—no immediate feedback and no details about how the request is made—are harder to deal with, but some amount of interactivity can be achieved by generating a response that includes client-side code (code executed by the browser), such as JavaScript or a Java applet. JSF user interface components can generate this code for you.