Carried out a discovery phase recently to look at Azure API Management and the key features gained by layering Azure’s API Manager (APIM) as a proxy/facade layer between your backend APIs. One of the elements of APIM that rather appealed to me was the “out of the box” caching.
The Easy Way
Playing with an POC API and one Operation I was quickly up and running with caching by simply defining a Policy to my API operation.
The MSDN documentation here is easy to follow, along with the implementation. For an API operation that’s unlikely to change it’s just a case of adding an Inbound policy to carry out a cache lookup and a outbound query to store the backend API response.
The additional attributes basically form the cache key. So, if you want to cache based on the subscription key or the product for example that can be achieved by specifying true on the attributes you care about. Things get a little tricky when trying to invalidate the cache. In fact there doesn’t appear to be an easy way (or any way?!) to invalidate the cache. This doesn’t really give me the flexibility I need. So onto…….
The Hard Way
Well it’s not really that hard but there’s not much documentation currently available on this approach. Even searches on StackOverflow result in empty responses and/or people complaining that Microsoft haven’t really made things easy here.
After a bit of trial and error I managed to get something like what I’d need. Basically, I used an approach of capturing the backend APIs response to a variable, storing this in the cache by a deterministic key and checking for this on Inbound requests then finally using some of the XSLT logic to either use the cached response in body of the response or call out to backend API for a fresh response.
Finally, I could then remove the cache key (and invalidate the cache) on POST, PATCH etc….
<cache-remove-value key=”getAllWidgets” />