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.
SonicSpike excerpts from CNet’s coverage of the latest in the seemingly inevitable path toward consistently applied Internet sales taxes for U.S citizens:
"Internet tax supporters are hoping that a vote in the U.S. Senate as early as today will finally give them enough political leverage to require Americans to pay sales taxes when shopping online. Sens. Mike Enzi (R-Wy.) and Dick Durbin (D-Ill.) are expected to offer an amendment to a Democratic budget resolution this week that, by allowing states to ‘collect taxes on remote sales,’ is intended to usher in the first national Internet sales tax."
There goes one of the best ways to vote with your dollars.
I use Netflix and my Xbox$7.99 a month compared to $65. Yes,, I can’t watch current TV programs but it’s all infomercials anyways. From CNET…