Conseils de limitation sur Microsoft Graph

La limitation restreint le nombre d’appels simultanés à un service pour empêcher la surutilisation des ressources. Microsoft Graph est conçu pour gérer un volume important de requêtes. Dans le cas d’un grand nombre de requêtes, la limitation permet de maintenir des performances optimales et la fiabilité du service Microsoft Graph.

Les limitations varient en fonction du scénario. Par exemple, si vous effectuez un grand volume d’écritures, la possibilité de limitation est plus élevée que si vous effectuez uniquement des lectures.

Remarque

Les solutions qui doivent extraire un grand volume de données de Microsoft Graph doivent utiliser Microsoft Graph Data Connect au lieu des API REST Microsoft Graph. Microsoft Graph Data Connect permet aux organisations d’extraire Microsoft 365 données en bloc sans être soumises à des limites.

Que se passe-t-il en cas de limitation ?

Lorsqu’un seuil de limitation est dépassé, Microsoft Graph limite toutes les demandes supplémentaires de ce client pendant une période donnée. En cas de limitation, Microsoft Graph retourne le code http status 429 (trop de requêtes) et les requêtes échouent. Un délai d’attente suggéré est retourné dans l’en-tête de réponse de la demande ayant échoué. Le comportement de limitation peut dépendre du type et du nombre de demandes. Par exemple, si vous avez un volume élevé de requêtes, tous les types de requêtes sont limités. Les limites de seuil varient en fonction du type de demande. Par conséquent, vous pouvez rencontrer un scénario où les écritures sont limitées, mais les lectures sont toujours autorisées.

Scénarios de limitation courants

Les causes les plus courantes de limitation de clients sont les suivantes :

• Un grand nombre de requêtes pour toutes les applications dans un client.
• Un grand nombre de requêtes à partir d’une application particulière sur tous les clients.

Exemple de réponse

Lorsque la valeur seuil de limitation est dépassée, Microsoft Graph répond par une réponse semblable à celle-ci.

HTTP/1.1 429 Too Many Requests
Content-Length: 312
Content-Type: application/json
Retry-After: 10

{
  "error": {
    "code": "TooManyRequests",
    "innerError": {
      "code": "429",
      "date": "2020-08-18T12:51:51",
      "message": "Please retry after",
      "request-id": "94fb3b52-452a-4535-a601-69e0a90e3aa2",
      "status": "429"
    },
    "message": "Please retry again later."
  }
}

Meilleures pratiques pour gérer la limitation

Les meilleures pratiques pour la gestion des limitations sont les suivantes :

• Réduisez le nombre d’opérations par requête.
• Réduisez la fréquence d’appels.
• Évitez les tentatives d’exécution immédiates, car toutes les requêtes s’accumulent par rapport à vos limites d’utilisation.

Lorsque vous implémentez la gestion des erreurs, utilisez le code d’erreur HTTP 429 pour détecter la limitation. La réponse ayant échoué inclut l’en-tête de Retry-After réponse. La sauvegarde des demandes à l’aide du Retry-After délai est le moyen le plus rapide de récupérer après la limitation, car Microsoft Graph continue à journaliser l’utilisation des ressources pendant qu’un client est limité.

1. Attendez le nombre de secondes spécifié dans l’en-tête Retry-After.
2. Retentez la requête.
3. Si la requête échoue à nouveau avec un code d’erreur 429, vous êtes toujours limité. Continuez à utiliser le délai recommandé Retry-After et réessayez la demande jusqu’à ce qu’elle aboutisse.

Toutes les ressources et API décrites dans la section Limites spécifiques aux services fournissent un Retry-After en-tête, sauf indication contraire.

Pour obtenir une description plus générale de la limitation dans Microsoft Cloud, consultez l’article relatif à la limitation.

Remarque

Si aucun en-tête Retry-After n’est fourni par la réponse, nous vous recommandons d’instaurer une stratégie de nouvelles tentatives de backoff exponentiel. Vous pouvez également appliquer des modèles plus avancés lors de la création d’applications à grande échelle.

Les kits de développement Microsoft Graph implémentent déjà des gestionnaires dépendant de l’en-tête Retry-After ou par défaut d’une stratégie de nouvelles tentatives de backoff exponentiel.

Meilleures pratiques pour gérer la limitation

Les modèles de programmation tels que l’interrogation continue d’une ressource pour rechercher les mises à jour et l’analyse régulière des collections de ressources pour rechercher les ressources nouvelles ou supprimées risquent davantage d’entrainer une limitation des applications et une dégradation des performances globales. Au lieu de cela, vous devez tirer parti du suivi des modifications et des notifications de modifications lorsque ces fonctions sont disponibles.

Remarque

Bonnes pratiques pour la découverte des fichiers et la détection des modifications à grande échelle : cette rubrique décrit les meilleures pratiques de manière générale.

Limitation et traitement par lots

Le traitement par lots JSON permet d’optimiser votre application en combinant plusieurs requêtes dans un seul objet JSON. Les demandes dans un lot sont évaluées individuellement par rapport aux limites de limitation et si une demande dépasse les limites, elle échoue avec un code status et 429 une erreur similaire à l’exemple de réponse précédent. Le lot lui-même réussit avec un code status de 200 (OK). Plusieurs demandes peuvent être limitées dans un seul lot. Vous devez retenter chaque demande échouée du lot à l'aide de la valeur fournie dans l'en-tête de réponse retry-after du contenu JSON. Vous pouvez réessayer toutes les demandes ayant échoué dans un nouveau lot après la valeur retry-after la plus longue.

Si les kits de développement logiciel (SDK) réappliquent des demandes automatiquement lorsqu’elles ne sont pas groupées, les demandes limitées qui faisaient partie d’un lot ne sont pas réessayées automatiquement.

Étape suivante

Identifier les limites de limitation pour différentes ressources Microsoft Graph