Java Web Services: Up and Running, 2nd Edition

Review of HTTP Requests and Responses

The next section has a REST-style sample service whose URL is:

http://localhost:8080/predictions/

If this URL is typed into a browser’s window, the browser generates a request similar to:

GET /predictions/ HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) Chrome/24.0.1312.56
Host: localhost:8080
Accept: text/html

The browser parses the entered URL into these parts, with clarifications below:

• GET /predictions/ HTTP/1.1

  This is the HTTP request start line:

  • GET is the HTTP method (verb).
  • /predictions/ is the URI (resource’s name).
  • HTTP/1.1 is the HTTP version that the requester is using.

• User-Agent: Mozilla/5.0 (X11; Linux x86_64) Chrome/24.0

  Immediately after the start line come the HTTP request header elements or headers for short. Each element is a key/value pair with a colon (:) separating the key on the left from the value on the right. In this element, User-Agent is the key, and everything to the right of the colon is the value. Chrome is the browser used in this request, and Mozilla/5.0 specifies a browser compatibility type. The User-Agent information also includes the operating system in use, 64-bit Linux. Of interest here is that key User-Agent captures the intended meaning: it is the application (agent) that a user employs to make a request.

• Host: localhost:8080

  In localhost:8080, the network address of the machine that hosts the resource is to the left of the colon; the port number, in this case 8080, is to the right. In this example, the network address is localhost and its dotted-decimal equivalent is 127.0.0.1. Because the network address is localhost, the web server and the requesting application are on the same machine, which is convenient during development. In a production environment, the web server might have a network address such as dcequip.cti.depaul.edu. Port numbers range from 0 to roughly 65000, with port numbers from 0 through 1023 typically reserved for standard applications such as web servers (port 80 for HTTP and port 443 for HTTPS), SMTP (email, port 25), SSH (secure shell, port 22), and so on. For convenience, the web servers Tomcat and Jetty use port 8080 by default, but the number can be changed (for example, to the standard HTTP port number 80). Under HTTP 1.1, the key/value pair, with Host as the key, is required. The other header elements are optional, although the ones shown here are typical.

• Accept: text/html

  This is the MIME type (text) and subtype (html), which the browser is ready to accept. The application running on the web server may not honor the requested type and respond instead with, for example, text/plain or text/xml.

In summary, the key/value pairs such as:

Accept: text/html

make up the HTTP request headers. These pairs may occur in any order and only the following pair:

Host: <network address>

is mandatory under HTTP 1.1.

Two newlines terminate the headers section. A GET request has no body; hence, a GET request consists only of the start line and the headers. A POST request always has a body, which may be empty. In a POST request, two newlines mark the end of the headers.

Because a GET request has no body, such a request often includes, in the URI, a query string that consists of key/value pairs. For example, this GET request:

http://.../products?id=27&category=boots

includes a query string with two key/value pairs: id is the first key and 27 is the value; category is the second key and boots is the value. The query string thus provides a way for a bodyless GET request to include information within the request. The query string data is encapsulated in the HTTP request headers. POST requests always have a body, which is usually nonempty. The body of a POST request holds key/value pairs as well.

If all goes well, sending an HTTP request to the URL:

http://localhost:8080/predictions/

leads to an HTTP response, which is similar to Example 1-2.

Example 1-2. The HTTP response message from the predictions service

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=35B1E3AA21EB7242FD2FC50044D2166A; Path=/predictions/;
Content-Type: text/html;charset=ISO-8859-1
Transfer-Encoding: chunked

<?xml version="1.0" encoding="UTF-8"?>
<java version="1.7.0" class="java.beans.XMLDecoder">
 <array class="predictions.Prediction" length="32">
  <void index="0">
   <object class="predictions.Prediction">
    <void property="what">
     <string>
        Managed holistic contingency will grow killer action-items.
     </string>
    </void>
    <void property="who">
     <string>
        Cornelius Tillman
     </string>
    </void>
   </object>
  </void>
  ...
</java>

The start line:

HTTP/1.1 200 OK

begins with the HTTP version in use on the server. Next comes the HTTP status code (SC for short) as a number (200) and in English (OK). Status codes in the 200 range signal success. Five header elements follow, including the name of the web server that sends the response and the content type of the response. Note that the response type is given as text/html rather than as what it actually is: text/xml. The reason is that my code, which generates the response, does not bother to set the content type; hence, the Apache-Coyote (that is, Tomcat) web server uses its default type of text/html. Two newline characters again separate the headers from the HTTP body, which can be empty. In this case, the body is an XML document that lists corporate predictions together with their predictors.