Guide de la limitation | Concepts de l’API Graph
Important
Nous vous recommandons fortement d’utiliser Microsoft Graph plutôt que l’API Graph Azure AD pour accéder aux ressources Azure Active Directory. Nos efforts de développement sont désormais axés sur Microsoft Graph et aucune autre amélioration n’est prévue pour l’API Graph Azure AD. Il existe un nombre très limité de scénarios pour lesquels l’API Graph Azure AD peut être encore appropriée ; pour plus d’informations, consultez le billet de blog Microsoft Graph ou l’API Azure AD dans le Centre de développement Office.
Qu’est-ce-que la limitation ?
La limitation limite le nombre d’appels simultanés à un service pour empêcher la surexploitation des ressources. Azure Active Directory (AD) Graph est conçu pour gérer un volume très élevé de demandes. Si le nombre de demandes est très important, la limitation permet de conserver des performances optimales et la fiabilité du service Azure AD Graph.
La limitation varie en fonction du scénario. Par exemple, si vous exécutez un grand volume d’opérations d’écriture sur votre locataire, vous serez plus amené à utiliser la limitation que si vous effectuez uniquement des opérations de lecture.
Que se passe-t-il en cas de limitation ?
Lorsqu’un seuil de limitation est dépassé, Azure AD Graph limite les demandes suivantes de ce locataire pendant que la limitation est appliquée. Quand la limitation est appliquée, Azure AD Graph renvoie le code d’état HTTP 429 (« Trop de demandes »), et les demandes échouent. Le comportement de la limitation peut être dépendant du type et du nombre de demandes. Par exemple, si vous avez un volume très élevé de demandes, tous les types de demandes sont limités. Les limites de seuil varient en fonction du type de demande. Par conséquent, vous pouvez rencontrer un scénario dans lequel les opérations d’écriture sont limitées alors que les opérations de lecture sont toujours autorisées.
Scénarios de limitation courants
Les causes les plus courantes de la limitation des clients sont entre autres :
- Un grand nombre de demandes sur toutes les applications dans un locataire.
- Un grand nombre de demandes d’une application spécifique sur tous les locataires.
Bonnes pratiques de gestion de la limitation
- Réduire le nombre d’opérations par demande.
- Réduire la fréquence des appels.
- Lorsque les requêtes échouent avec un code d’erreur HTTP 429, attendez le nombre de secondes spécifié dans le champ d’en-tête de réponse Retry-After et relancez la requête.
Lors de l’implémentation de la gestion des erreurs, utilisez le code d’erreur HTTP 429 pour détecter la limitation. La réponse d’échec inclura le champ Retry-After dans l’en-tête de réponse.
- Attendez le nombre de secondes spécifié dans le champ Retry-After.
- Relancez la demande.
- Si la demande échoue à nouveau avec un code d’erreur 429, la limitation est toujours appliquée. Continuez à respecter le délai Retry-After recommandé et relancez la demande jusqu'à sa réussite.
L’interruption de demandes à l’aide du délai Retry-After est le moyen le plus rapide pour récupérer de la limitation, car AAD Graph continue à journaliser l’utilisation des ressources pendant qu’un locataire est limité. Vous devez éviter des nouvelles tentatives immédiates, car l’accumulation des requêtes peut entraîner un dépassement de vos limites d’utilisation.
Pour plus d’informations sur la limitation sur Microsoft Cloud, consultez Modèle de limitation.