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 reasonable
to use If-Modified-Since and 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 to stat(2) a file than to open it and read its data into memory.
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 HTTP Cache-Control header provides a way to specify cache semantics not
covered by other HTTPmechanisms. This header provides the following features,
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 HTTPsemantics, 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.
Pages:
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327