HTML and CSS Reference
Do not be afraid of URLs. Most resources should be identified only by URLs. For example, a customer record
should have a URL such as http://example.com/patroninfo/username rather than
http://example.com/patroninfo. That is, each customer should have a separate URL that links directly to her
record (protected by a password, of course), rather than all your customers sharing a single URL whose content
changes depending on the value of some login cookie.
Safe, Side-Effect-Free Operations Such as Querying or Browsing Operate via GET
Google can only index pages that are accessed via GET. Users can only bookmark pages that are accessed via
GET. Other sites can only link to pages with GET. If you care about raising your site traffic at all, you need to
make as much of it as possible accessible via GET.
Nonsafe Operations Such as Purchasing an Item or Adding a Comment to a Page Operate via
Web spiders routinely follow links on a page that are accessible via GET, sometimes even when they are told not
to. Users type URLs into browser location bars and then edit them to see what happens. Browsers prefetch
linked pages. If an operation such as deleting content, agreeing to a contract, or placing an order is performed
via GET, some program somewhere is going to do it without asking or consulting an actual user, sometimes with
disastrous consequences. Entire sites have disappeared when Google discovered them and began to follow
"delete this page" links, all because GET was used instead of POST.
Each Request Is Independent of All Others
The client and server may each have state, but neither relies on the other side remembering what its state is.
All necessary information is transferred in each communication. Statelessness enables scalability through
caching and proxy servers. It also enables a server to be easily replaced by a server farm as necessary. There's
no requirement that the same server respond to the same client two times in a row.
Robust, scalable web applications work with HTTP rather than against it. RESTful applications can do everything
that more familiar client/server applications do, and they can do it at scale. However, implementing this may
require some of the largest changes to your systems. Nonetheless, if you're experiencing scalability problems,
these can be among the most critical refactorings to make.