3. BUILDING FOR SEARCH ENGINES: FOLLOWING REST 21
Actually, that’s not quite true. There are other verbs besides GET and POST (although those are by far the most common). There’s GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, TRACE (and probably others). GET and POST we’ve already seen. HEAD is like GET but only requests the headers or a page and not the actual content. PUT is there if you want to replace the contents of the page with something entirely new—TimBL’s original web browser used PUT whenever you tried to save a change you made to a page. PATCH is like PUT but only changes part of a page. DELETE, MOVE, COPY, LOCK, and UNLOCK should be pretty self-explanatory. CONNECT is used for proxying and tunneling other stuff. OPTIONS lets you find out what the server supports. PROPFIND and PROPPATCH are used for setting properties in the WebDAV protocol. MKCOL is for making a WebDAV collection. (These probably shouldn’t have all gotten their own methods...) TRACE asks the server to just repeat back the request it got (it’s useful for debugging).
But, frankly, GET and POST are the most frequently used, in no small part because they’re the ones supported by all Web browsers. GET, of course, is used every time you enter a URL or click on a link, while POST can be used in some forms. (Other forms are still GET, since they don’t change anything.)
Following these rules is called following REST, after the 2000 Ph.D. dissertation of Roy Fielding, coauthor (with Tim Berners-Lee and some others) of the official HTTP specification (RFC 2616, if you’re interested). Roy, a big bear of a man with a penchant for sports, set out to describe theoretically the various styles (“architectures”) of network-based applications. Then he describes the interesting hybrid that the Web adopted, which he terms “Representational State Transfer” or REST.
While REST is often used to mean something akin to “use GET and POST correctly,” it’s actually much more complicated, and more interesting, and we’ll spend a little time on it just so you can see the different kind of architectural tradeoffs that those Masters of the Universe who have to design a system like the Web have to think about.
The first choice made was that the Web would be a client-server system. Honestly, the Web is probably this way because Tim did things this way and Tim did thinks this way because that’s how everything else on the Internet was back then. But it’s not impossible to imagine that the Web could have been more peer-
