There’s a couple of things to think about when considering caching – it is not enough to just look at the cache control header and turn off caching. We absolutely want to enable caching in a rich way as it is critical in many scenarios. For example:
1) We want to enable conditional requests based on e-tags so that we don’t send content across the wire if there is no change.
2) If a response is cacheable then we need to indicate whether it has been content negotiated by using the Vary header field
3) We want to allow users to set the cache policy (which is reflected in the cache control header) in a way that makes sense for a particular API.
Comments: All of above is handled in CacheCow library: https://github.com/aliostad/CacheCow I think there is still work needed to make defining cache policy easier. Currently I have a single entry point that receives all calls for the policy and we can build abstractions there. If it makes sense, I am happy to work with the team to bring the server-side of CacheCow into the ASP.NET Web API. At the end of the day, CacheCow was built on the Glenn's original idea :)
1) We want to enable conditional requests based on e-tags so that we don’t send content across the wire if there is no change.
2) If a response is cacheable then we need to indicate whether it has been content negotiated by using the Vary header field
3) We want to allow users to set the cache policy (which is reflected in the cache control header) in a way that makes sense for a particular API.
Comments: All of above is handled in CacheCow library: https://github.com/aliostad/CacheCow I think there is still work needed to make defining cache policy easier. Currently I have a single entry point that receives all calls for the policy and we can build abstractions there. If it makes sense, I am happy to work with the team to bring the server-side of CacheCow into the ASP.NET Web API. At the end of the day, CacheCow was built on the Glenn's original idea :)