208 | Chapter 7: REST, Resources, and Web Services
the entire body. But if the calculated ETag matches the one the client sent, a 304
Not Modified response is returned.
There are many different strategies for calculating entity tags, depending on the
application’s needs. The simple strategy of hashing the response body works,
but it can be inefficient as the server must still generate and hash the response.
For dynamic content, this can be extremely inefficient (and it may be more rea-
sonable to useIf-Modified-Sinceand compare it against a timestamp on the
source data).
The solution often used for static content is to incorporate the file’s inode, as it
can be much faster tostat(2)a file than to open it and read its data into mem-
ory. This works well, but it cannot be used in clusters where the data resides on
separate filesystems among systems in the cluster.
Rails provides transparent ETag support, which we will revisit later in this
chapter.Cache-Control header
The HTTPCache-Controlheader provides a way to specify cache semantics not
covered by other HTT Pmechanisms. This header provides the following fea-
tures, and more:
- Clients can request a response that may be old, but by only up to a certain
amount of time (max-age). - Clients and servers can dictate that certain information never be cached by
intermediate shared caches (private), or by any cache (no-cache). - The caching protocol can be extended without breaking HTT Psemantics, if
agreed upon by the client and server and implemented thus.
Robustness to Change
Another advantage conferred by RESTful design is that the designs tend to be more
resilient to change than RPC-style interfaces. RESTful design drives the architectural
decisions into noun territory. Noun selection tends to be domain-driven, while RPC
interfaces tend to be more implementation-driven, as they expose their procedures
(an implementation detail) as part of the interface. While RPC interfaces often need
an extra layer of indirection to separate the interface from the implementation, REST
cultivates a separation of interface and implementation by encouraging more abstract
interfaces.
Also, because REST distinguishes the idea of “resource” from “representation,” it is
easy to add new content types representing the same resource as new formats are
required. No architectural changes are required, as REST is based on a separation
between an abstract resource and its representations.