API:Cache de données

Contrôle du cache client

Le protocole HTTP permet de contrôler comment les navigateurs internet et les serveurs proxys mettent le contenu en cache, à l'aide de différentes valeurs spécifiées dans le header Cache-Control. (Ceci marche uniquement pour les requêtes GET.) Cette API permet au client d'affecter deux de ces valeurs, max-age et s-maxage, à l'aide des paramètres de l'API maxage et smaxage.

maxage indique au navigateur combien de temps la réponse doit rester en cache (en secondes). smaxage fait la même chose pour les proxies partagés. En pratique, ce dernier est notamment utilisé pour informer le proxy inverse du côté serveur (tel que Varnish de Wikimedia)

Les erreurs ne sont jamais placées en cache. Les réponses spécifiques aux utilisateurs seront marquées avec Cache-Control: private afin que le navigateur les mette en cache, mais pas les proxies publics. Actuellement, l'API utilise les paramètres de langage par défaut d'un utilisateur authentifié, ainsi les réponses à un utilisateur authentifié sont toujours privées. Cela peut être évité en ajoutant le paramètre d'API uselang=content (T97096).

Améliorer le cache hit ratio

Une requête est chargée à partir du cache seulement si cette URL exacte a été mise en cache. (Par exemple, si vous exécutez la même requête avec maxage=1800 puis avec maxage=3600, la seconde ne pourra pas utiliser le cache de la première, puisque le paramètre maxage rend l'URL différente). Si vous passez une liste de pages en paramètre, vous pouvez améliorer le ratio d'appels au cache en les triant et en enlevant les doublons.

Contrôler le cache à partir d'un module API

La mise en cache est spécifiée par les méthodes ApiMain::setCache*. Typiquement, la mise en cache sera seulement un souci dans les sous-modules query , qui doivent utiliser la méthode getCacheMode à la place, qu'ils héritent de ApiQueryBase.