The action API (api.php) supports caching for a user-defined period of time, but does not support cache invalidation, which is problematic for functionality that's under high load but might need to be updated immediately to reflect changes or remove vandalism, personal data etc. With the recent opensourcing of hashninja, maybe that can change. A possible approach to add partial cache invalidation could be:
- install the Xkey (aka hashtwo/hashninja) Varnish module
- every time the API is called, decide if it is a purgeable request (to cut down the number of URLs that need to be purged) - to be purgeable, it must invoke a single module, it must be about a single target (title, revision, file etc), the parameters must be in lexicographic order, for list parameters the content must be in lexicographic order, and it cannot have any non-enum parameter apart from the object identifier (e.g. title). Or maybe that could be relaxed a bit, depending on the hashninja performance and API usage stats.
- on purgeable requests have the API module output a bunch of Xkey HTTP headers with an invalidation tag each, such as id:<page_id>
- have MediaWiki send an appropriate purge request (a normal HTTP request with an Xkey-Purge HTTP header containing a list of invalidation tags) on every content update