Digging Deeper Into HTTP

In the previous article, I explained the basics of HTTP including client requests and server responses. In this article, we’ll dig into it in greater detail.

Request Methods

There are different types of requests, which are known as request methods. The most common request method is GET, which a client will use to fetch a resource from a web server. But a client may also want to send data to a server, edit data on the server, or even delete data from a server. There is a request method for each of these actions:

• GET — The client is requesting to fetch a resource from a web server.
• POST — The client is requesting to add data to the web server.
• PUT — The client is requesting to edit information that is on the web server.
• DELETE — The client is requesting to remove data from the web server.

There are a few other types of requests, but these four are the most common. The best example of a POST request is when a web page has an HTML form on it. When a user enters data into the form and presses the submit button, the browser makes a POST request and sends the user’s information to the web server. Here’s an example of a POST request:

The first line of the request has the method (POST), the path to a PHP page on the server that will process the data (hobby-survey-form.php), and the version of HTTP being used. The next three lines are headers. And following the blank line is the body of the request, which contains the data that was entered by the user. Take a look at the Content-Type header, this header specifies the format of the data being sent. When HTML forms are submitted, the browser encodes the data in a format known as application/x-www-form-urlencoded. This format requires data to be encoded in key/value pairs, with each pair separated by an ampersand. The key and its corresponding value are separated by an equals sign. You can think of the key as the label for the data, while the value is the actual data. In the request shown above, you can see that the first pair has a key (label) of firstName and a value of Bob.

When this request reaches the web server, the server will find the hobby-survey-form.php file and hand off the data to it. The PHP page can then process the data, usually by adding a record to a database on the server. Then the web server will put together its response, which might look like this:

Query Strings

In the previous article we discussed how additional information can be sent with a request by using HTTP headers, but information can also be added by appending data to a URL. Take a look at the following URL:

Notice the question mark, and what comes after it. In a URL, everything after the question mark is the query string. It looks a lot like the body of the previous POST request. By default, the data in a query string and the data in the body of a POST request use the same type of formatting (key/value pairs separated by ampersands). One interesting thing about a URL with a query string is that you can bookmark it and the additional information will be included.

Notice what happens to the URL when you run a Google search and view the results. When the results page appears, you’ll see that your search terms are added to the URL as a query string. This allows you to copy the URL. Then you can email the URL to someone so that when they press on the link, they will see the same results. This is also done on e-commerce sites, such as Amazon.

HTTP is ‘stateless’

If you create a website that uses JavaScript to set some variables on one of the pages, what happens to those variables when the user clicks on a link and navigates to another page on your site? Unfortunately, all those variables are lost, and they would need to somehow be recreated when the new page loads. The values of all the variables on a page is known as the ‘state’.

Web pages, by default, do not maintain state as you navigate from one page to another within a website. So HTTP is considered to be ‘stateless’ because it does not include a way to send the state of a page in a request. But you can use cookies to allow data to persist from one page request to another while navigating through a web site.

Cookies

Cookies help us to overcome the stateless nature of HTTP. If we wanted to keep track of a variable (let’s call it ‘UserName’), as a visitor moves from one web page to another on a website, we could configure it to set cookies.

The server sets a cookie by sending a ‘Set-Cookie’ header in the response. The browser then saves the information in a file (the file is known as the cookie), and with every additional request to the server, it sends the cookie information back to the server in the ‘cookie’ header. Here’s what the first few lines of a server response might look like when a cookie is set :

The browser would then store the information (UserName = Bob) in a cookie file, and it will send the information with every subsequent request to the same web server. So the next request by the browser might look like something like this:

The server receives the request and it will now know that the request is made by Bob. Let’s assume that Bob then clicks on a link to another web page on the site. The request that the browser generates might start like this:

The server would receive this request, and again know that it is Bob asking for some-other-page.html. So you can see how cookies allow us to retain information as a user navigates through our website.

There is a lot more to cookies than what we discussed here, for example a server can set an expiration date for a cookie when it sends it to the browser. Then the browser will stop sending the cookie header when that date has passed.

RESTful Web Services

Nowadays, many web sites do not generate responses that include HTML. Instead they just return data. These are known as web APIs or web services, and they have become an extremely powerful method for developing programs and integrating systems. Because they return raw data (rather than data that is displayed within a bunch of HTML tags), the data can be ‘consumed’ by different client applications. You could build a mobile app that uses the data, or you could build a desktop app that consumes data from a web service. You could also use AJAX to build a website that consumes web services. Web services offer a lot of flexibility, because you can build many variations of client applications that ‘consume’ the data they provide. Web services also offer many opportunities to integrate systems. Many businesses build web services to share data with other businesses, which allows for different systems to integrate with one another.

Summary

In 2009 Google declared that ‘the web has won’, meaning the web has become the dominant platform for software development. The widespread usage of HTTP and the emergence of web APIs has created great demand for web developers. Every web developer should have solid understanding of HTTP and how it can be used to build web applications.