Single purpose media types and caching

My recent post asking people to refrain from creating more generic hypermedia types sparked some good conversation on twitter between @mamund, @cometaj2, @mogsie, @inadarei and others.  Whilst thinking some more on the potential benefits of single purpose media types versus generic hypermedia types, realized there is a correlation between single purpose media types and representation lifetimes.  I thought it might be worth adding to the conversation, but there is no way I could fit it in 140 chars, so I’m posting it here.

Age matters

When I say representation lifetime, I am referring to how long a representation can be considered to be still fresh, from the perspective of caching.   The lifetime of a representation can be explicitly defined by either setting the Expires header or by setting the max-age parameter of the cache-control header.  If neither of these values are set then a client can choose to use heuristics to determine how long the response could still be fresh for.

When using Single purpose media types, those types often hint at representations that should have different lifetimes.  If you are building an HTML dashboard that contains images of charts showing KPIs (key performance indicators), then the HTML will likely have a much longer lifetime than that of the images.

However, if you are building a dynamic HTML application, then the HTML is likely to have a shorter lifespan than the images displayed on it.  Media types that provide metadata like CSS, or API discovery documents are likely to have long lifetimes, whereas media types that display status information are likely to be very short lived.

Hints for client heuristics

When I was reading the specification for apisjson I noticed that they had explicitly added a clause to say that if no lifetime information was provided then a lifetime of 7 days would be an appropriate value.  I think the idea of a media type specification explicitly stating suggested lifetime values is very interesting.  When chatting with Steven Wilmott at API Craft Meetup SF he mentioned that they had got the idea from the standard convention of caching robots.txt for 24 hours. 

Just a thought

As I mentioned, this is simply an overly long tweet, rather than a blog post.  Nothing ground breaking, but I find that developers often forget about the value of setting caching headers.  If media type designers can provide guidance on what appropriate values might be then developers might pay a little more attention and the Internet might just get a little faster.

Image Credit: Best before date https://flic.kr/p/6MAMum