API:Caching data

Controlling caching from a client
The HTTP protocol allows controlling how browsers and web proxies cache content, via various values specified to the header. (This only works for GET requests.) The API allows the client to set two of these values, and , via the API parameters  and.

tells the browser how long the response should be cached (in seconds). does the same for shared proxies. In practice the latter is typically used to instruct the server-side reverse proxy (such as Wikimedia's ).

Errors are never cached. User-specific responses will be marked as so the browser will cache them but public proxies won't.  Currently the API uses a logged-in user's language setting by default, so responses to logged-in users are always private. This can be avoided by adding the API parameter ( T97096 ).

Improving cache hit ratio
A request is only served from cache if that exact URL has been catched. (E.g. if you make the same request with and then with , the second won't be able to use the first's cache entry because the different  parameter makes the URL different.) If you pass a list of pages as a parameter, you might improve cache hit ratio by sorting and deduplicating them.

Controlling caching from an API module
Caching is specified by the booty methods. Typically caching is only going to be a concern in the submodules, which should use  method instead, which they inherit from.