Refactoring - Refactoring HTML: Improving the Design of Existing Web Applications - page 20

Finally, let's not neglect the importance of CSS for our network managers and accountants. There may be only a
kilobyte or two of purely presentational information in each page. However, summed over thousands of pages
and millions of users, those kilobytes add up. You get real bandwidth savings by loading the styles only once
instead of with every page. When ESPN switched to CSS markup it saved about two terabytes of data a day . At
that level, this translates into real cost savings that you can measure on the bottom line. Now, admittedly, most
of us are not ESPN and can only dream of having two terabytes of daily traffic in the first place, much less two
terabytes of daily traffic that we can save. Nonetheless, if you are experiencing overloaded pipes or are
unexpectedly promoted to the front page of Digg, moving your style into external CSS stylesheets can help you
handle that.
Why REST
Representational State Transfer (REST) is the oldest and yet least familiar of the three refactoring goals I
present here. Although I'll mostly focus on HTML in this topic, one can't ignore the protocol by which HTML
travels. That protocol is HTTP, and REST is the architecture of HTTP.
Understanding HTTP and REST has important consequences for how you design web applications. Anytime you
place a form in a page, or use AJAX to send data back and forth to a JavaScript program, you're using HTTP.
Use HTTP correctly and you'll develop robust, secure, scalable applications. Use it incorrectly and the best you
can hope for is a marginally functional system. The worst that can happen, however, is pretty bad: a web spider
that deletes your entire site, a shopping center that melts down under heavy traffic during the Christmas
shopping season, or a site that search engines can't index and users can't find.
Although basic static HTML pages are inherently RESTful, most web applications that are more complex are not.
In particular, you must consider REST anytime your application involves the following common things:
Forms
User authentication
Cookies
Sessions
State
These are very easy to get wrong, and more applications to this day get them wrong than right. The Web is not
a LAN. The techniques that worked for limited client/server systems of a few dozen to a few hundred users do
not scale to web systems that must accommodate thousands to millions of users. Client/server architectures
based on sessions and persistent connections are simply not possible on the Web. Attempts to recreate them
fail at scale, often with disastrous consequences.
REST, as implemented in HTTP, has several key ideas, which are discussed in the following sections.
All Resources Are Identified by URLs
Tagging distinct resources with distinct URLs enables bookmarking, linking, search engine storage, and painting
on billboards. It is much easier to find a resource when you can say, "Go to http://www.example.com/foo/bar "
than when you have to say, "Go to http://www.example.com/ . Type 'bar' into the form field. Then press the foo
button."