Because caching behavior is so application-dependent, the decision was made for
HTTPto provide mechanisms for caching without specifying actual behavior or client/
server responsibility in great detail. As Fielding describes it (in section 6.3.2.6 of his
thesis):
Because REST tries to balance the need for efficient, low-latency behavior with the desire
for semantically transparent cache behavior, it is critical that HTTPallow the application
to determine the caching requirements rather than hard-code it into the protocol
itself. The most important thing for the protocol to do is to fully and accurately
describe the data being transferred, so that no application is fooled into thinking it has
one thing when it actually has something else. HTTP/1.1 does this through the addition
of the Cache-Control, Age, Etag, and Vary header fields.
Section 13 of the HTTP/1.1 specification (RFC 2616) details HTTP??™s caching behavior.*
HTTPprovides several features for cache control, which interact to provide a framework
on which servers, clients, and intermediaries can build a caching policy. These
features include the following:
Conditional GET
A conditional GET is an HTTP GET request containing one or more additional
header fields specifying conditions under which the requested resource should or
should not be sent. It is used in conjunction with the Last-Modified header and/or
entity tags, discussed next.
Pages:
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325