Jump to content

API:Etiquette

From mediawiki.org
This page is a translated version of the page API:Etiquette and the translation is 96% complete.
Outdated translations are marked like this.

Cette page contient les meilleures pratiques à suivre pour utiliser l'API.

Comportement

Demande de limitation

Il n'existe pas de limites codées en dur et rapides pour les requêtes en lecture, mais réfléchissez bien et essayez de ne pas surcharger les sites. La plupart des administrateurs système se réservent le droit de vous bloquer tout simplement, si vous portez atteinte à la stabilité de leur site.

En envoyant vos requêtes en série plutôt qu'en parallèle, en attendant qu'une requête se termine avant d'envoyer la suivante, vous pouvez atteindre un taux de requêtes respectable. Nous recommandons aussi de regrouper plusieurs éléments dans une seule requête en :

  • utilisant le caractère pipe (|) à chaque fois que cela est possible par exemple titles=PageA|PageB|PageC, au lieu de faire un nouvelle requête pour chaque titre.
  • utilisant un générateur au lieu de faire une requête pour chaque résultat venant d'une autre requête.
  • Utilisez la compression GZip lorsque vous faites des appels à l'API en initialisant Accept-Encoding: gzip pour réduire l'utilisation de la bande passante.

Le nombre de requêtes qui font des modifications, qui changent l'état ou autre et donc qui ne sont pas des requêtes en lecture seule, peut être limité par période de temps. La valeur exacte du seuil appliqué peut être fonction du type d'action, de vos droits utilisateur et de la configuration du site web à qui vous faites la requête. Les limites vous concernant peuvent être déterminées quand vous vous connectez au point d'accès de l'API action=query&meta=userinfo&uiprop=ratelimits.

Lorsque vous atteignez la limite correspondant au seuil des requêtes, vous recevrez une API error response avec l'erreur code ratelimited. Si vous rencontrez cette erreur, vous pouvez retenter cette requête, mais en augmentant le temps entre chaque requête. Une stratégie commune pour cela est l'Exponential backoff.

Analyser les révisions

Alors qu'il est possible d'obtenir des résultats pour un numéro de révision spécifique en utilisant le paramètre revid, ceci reste une opération coûteuse pour les serveurs. Pour récupérer une révision spécifique utilisez le paramètre oldid. Par exemple :

Paramètre maxlag

Si votre tâche n'est pas interactive (c'est à dire que l'utilisateur n'attend pas le résultat) vous devez utiliser le paramètre maxlag . La valeur du paramètre maxlag doit être un nombre entier de secondes. Par exemple :

Ceci empêche votre tâche de s'exécuter quand la charge des serveurs est importante. Les valeurs hautes impliquent un comportement plus aggressif, les valeurs basses sont plus agréables.

Voir Manuel:Paramètre maxlag pour plus de détails.

Entête de l'agent utilisateur

Il est bon de s'habituer à initialiser l'entête descriptif de l'agent utilisateur. Pour faire cela, utilisez User-Agent: clientname/version (contact information e.g username, email) framework/version.... Par exemple en PHP :

ini_set('user_agent', 'MyCoolTool/1.1 (https://example.org/MyCoolTool/; MyCoolTool@example.org) UsedBaseLibrary/1.4');

Ne recopiez pas simplement l'agent utilisateur d'un navigateur web populaire. Cela assure que si un problème apparait réellement, il est facile de tracer son origine.

Si vous appelez l'API à partir d'un navigateur basé sur JavaScript, il est possible que vous ne puissiez pas influer sur l'entête User-Agent - cela dépend du navigateur. Pour contourner cela, utilisez l'entête Api-User-Agent .

Voir m:User-Agent_policy pour plus de détails.

Formats des données

Tous les nouveaux utilisateurs de l'API doivent utiliser JSON . Voir API:Data formats/fr pour plus de détails.

Performances

Télécharger un grand nombre de données n'est pas toujours très efficace si vous utilisez l'API Action. Sur les wikis Wikimedia, il existe des manières plus rapides pour obtenir des données en masse, voir m:Research:Data et wikitech:Portal:Data Services pour d'autres détails.

Autres notes

Si vos requêtes ramènent des données qui peuvent être mises en cache pour un moment, vous devrez procéder par étapes pour cela, de sorte à ne pas redemander les mêmes données plusieurs fois. Certains clients peuvent mettre en cache les données eux-mêmes, mais pour les autres (particulièrement pour les clients JavaScript), cela n'est pas possible.

C'est pourquoi, lorsque vous lisez des données à partir de l'API des services web, vous devez utiliser le plus possible les requêtes GET et non pas POST, car ces dernières ne peuvent pas être mises dans le cache.

In exceptional cases where you really need to use POST for a read request, such as calling action=parse with a long string of wikitext, consider setting the Promise-Non-Write-API-Action: true header. This helps ensure that your POST request is processed by an application server in the closest data center, if appropriate. There is no need to set this header for GET requests, and neither should it be set when making cross-wiki requests within a wiki family using CentralAuth; see tâche T91820.

Voir aussi