We’re mapping out the chapter on caching; lots of discussions back and forth. We both think this will be an important part of the book.
So far, here are some key topics we plan to cover:
- Validation Caching for Dynamic Resources (ETags, Last-Modified-Date. etc)
- Expiration Caching for Static Resources (Expires, Max-Age, etc.)
- Caching Composite Resources (Can you? Should you?)
- Keeping Resource Caches Fresh (Using Vary, Location, and other Cache-control elements to keep intermediaries up-to-date)
- Cache Invalidation and Back-end Data Stores (When the data store gets updated, how does the web cache get back in sync?)
- Client Caching Techniques (If you’re writing an HTTP client, you need to support browser-like caching)
Are these the right things to cover? Are there others we missed?
{ 12 comments… read them below or add one }
Looks like a good list to me.
Colin:
Thanks for the feedback. Feel free to expand on any items you like/don’t like here. Including other posts as we go along.
for the client-side caching, i’d like to see the difference between implementing caching in the app, and having a caching-aware client-side framework. specifically, with a caching-aware client-side framework, clients can use shared caches, which can be a huge benefit in scenarios where cached resources can be shared across applications (think about map tiles when you have various map-based applications installed, and they all request map tiles).
If I understand you, you’re talking about the diff between using local or shared caching on the client side, right?
if by “local” you mean cached in the client-side HTTP implementation’s application-specific cache, and by “shared” you mean cached in the client-side HTTP implementation’s cache that is shared by all applications using HTTP on the client, then you’re right.
dret:
Yep. I think I got it – thanks for the feedback. We’ll try to keep this blog up-to-date on things we cover.
It is an really important subject. Covering all these points is a rather big work. I do not see any other subject missing.
Your book will be definitely worth a read !
The cache invalidation sounds very interesting, especially when dealing with transactional resources, or invalidating batches (i.e. saying that 3 elements out of 10 are invalid).
Will:
Maybe you’re thinking of Cache Channels?
http://www.mnot.net/cache_channels/
Remind people that contrary to wide-spread belief POST responses MAY still be cached
Igor:
Good point. There are actually two important items when dealing w/ caches and the POST method
1 – If cache control information is sent w/ the POST *response* (Cache-Control header, maybe even ETag/Last-Modified) then the client/proxy has the option to cache the response based on the directives ( RFC2616, section 9.5).
2 – Regardless of the cache control info returned in a POST response, any *existing* copy of the resource must be invalidated when handling the POST *request* (RFC2616, section 13.10).
On the question “Can you? Should you?”:
When reading about RESTful ideas I constantly ask myself: What will be the consequence of this in terms of the ‘C’ the ‘A’ and the ‘P’ in the CAP theorem.
It would be great if in each of the 60 recipes you consider you address three isses: Consitency, Availability, Partitionability
AFAIK there is no ‘REST is a known exception to the CAP theroem’ conjecture
It would be great if you book could shed light on the CAP implication of the alternatives/suggestions you prefer.
TIA
{ 1 trackback }