206 | Chapter 7: REST, Resources, and Web Services
Conceptual Simplicity
The cornerstone of REST is simplicity. The decision to use a standard set of verbs
(whether the HTT Pverbs or some other set) virtually eliminates an entire area of dis-
cussion. The uniform registration and naming system of MIME types certainly
doesn’t settle the debate, but it definitely simplifies it.
With those two corners of the REST triangle taken care of, potentially the biggest
gray area is in identifying and naming resources. Naming is one area where simplic-
ity really pays off, because it is very easy to get it wrong. However, if you stick with a
standard set of verbs and content types religiously, they will help constrain your
choice of nouns.
It is very important to define clean, readable, persistent URIs for your resources. The
REST FAQ (http://rest.blueoxen.net/cgi-bin/wiki.pl?RestFaq) makes a good observa-
tion about naming:
GET is restricted to a single-URL line and that sort of enforces a good design principle
that everything interesting on the Web should be URL-addressable. If you want to
make a system where interesting stuff is not URL-addressable, then you need to justify
that decision.This is what designers and architects mean when they say “constraints are freeing.”
The principles of REST were derived from examination of how the Web and other
hypertext networks actually work. Rather than being some set of arbitrary restric-
tions, they embody the way that the Web should act.
By working within the principles of REST, any pain you may feel should be treated as
a hint that you might be going against the grain of the Web’s natural architecture. It
is certainly possible that your particular case is a special one. Certain application
domains just do not fit well into the REST paradigm. (REST has been described as
“Turing-complete” in a parallel with programming languages. Though any applica-
tion may be expressed in terms of REST, some may be much more conducive to
REST than others.) But trying to push yourself into the REST paradigm forces you to
defend any exceptions and special cases, and in doing so you may find that the
exceptions were not necessary after all.
Caching and Scalability
REST fits perfectly with the Railsshared-nothingphilosophy—the idea that the only
communication between application servers should be through the database (in
REST terms, by “modifying resource state”). We mentioned previously how this
assists scalability; the fewer interactions necessary between application servers, the
easier it is to scale them horizontally when load dictates.
Caching is well known as a hard problem. Phil Karlton famously called cache invali-
dation one of the “two hard things in Computer Science.” One of the requirements
of HTT Pcaching istransparency; the semantics of the information transferred must