HTTP Basics for REST-Based App Development
Courtesy Patrick Steele, VisualStudioMagazine.com
While typing in a URL and pressing Enter inside a browser is effortless, there’s a lot more going on behind the scenes. In this article, I’ll review some of the basics of HTTP and show how they’re being used in today’s modern, REST-based applications.
Tools of the Trade
Examining the raw HTTP traffic that goes back and forth between a client and server is actually quite easy these days. Many modern browsers allow you to view all of the network traffic they transmit and receive. I wrote an article earlier this year on using Chrome’s developer tools to examine network traffic (using the "Network" panel). If you’re running outside the browser, you may want to consider Fiddler2. It’s a standalone Windows Forms application that can monitor and display traffic from any running application, as shown in Figure 1.
[Click on image for larger view.]Figure 1. Sample Fiddler2 screen.
There are two main HTTP protocols: Version 1.0 and Version 1.1. I could spend an entire article going over the differences between the two. For brevity’s sake, the key takeaway is that HTTP 1.1 was designed to be backward-compatible with 1.0. The 1.1 specification took the (never formally specified) 1.0 protocol and added some enhancements and clarifications. For this article, I’ll be describing the 1.1 protocol, as many REST-based services require the 1.1 protocol.
HTTP is a very simple protocol — by design. A simpler protocol is easy to implement and, therefore, easier to adopt. Obviously, this simplicity has paid off: HTTP is used by millions of applications every day, most of those Web browsers (on both regular and mobile devices).
Every HTTP message is single request and a single response. That’s it. No complicated sequences or any special handshaking. A client opens a connection (by default, on port 80) and sends a request to the server. The server processes the request and sends back a response. The connection is closed. This is done for every message. Obviously, with a connection being opened and closed each time, HTTP is a stateless protocol. Any state information to be shared between client and server must be retransmitted on each request. By being stateless, subsequent HTTP requests don’t need to go to the same server as the first request (this makes a load balancer’s job much easier).
If you’ve ever done any Web forms development and seen the giant hidden field called "__VIEWSTATE," that’s an example of state transmission. The state of every control on a Web forms page is passed back and forth. This allows the server to "rehydrate" the state of the Web form, act on the request and send back a complete "state" of the new Web form. This response is then processed by the browser by rendering an updated page.