Caching Read-Write Web Services

by mike on May 23, 2009

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 }

Colin Jack May 23, 2009 at 9:35 am

Looks like a good list to me.


mike May 23, 2009 at 1:18 pm


Thanks for the feedback. Feel free to expand on any items you like/don’t like here. Including other posts as we go along.


dret May 24, 2009 at 6:21 pm

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).


mike May 24, 2009 at 9:28 pm

If I understand you, you’re talking about the diff between using local or shared caching on the client side, right?


dret May 26, 2009 at 8:33 am

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.


mike May 26, 2009 at 9:42 pm


Yep. I think I got it – thanks for the feedback. We’ll try to keep this blog up-to-date on things we cover.


David MARTIN May 25, 2009 at 4:52 pm

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 !


Will Sargent May 26, 2009 at 4:28 am

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).


mike June 1, 2009 at 11:54 am


Maybe you’re thinking of Cache Channels?


Igor June 2, 2009 at 5:08 pm

Remind people that contrary to wide-spread belief POST responses MAY still be cached


mike June 2, 2009 at 5:55 pm


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).


Hedge July 30, 2009 at 9:02 am

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.



Leave a Comment

{ 1 trackback }

Previous post:

Next post: