Réponses aux erreurs

Réponses d'erreur standard

Si une requête de l'API Management aboutit, l'API renvoie un code d'état 200. Si une erreur se produit lors d'une requête, l'API renvoie un code d'état HTTP, un état et un motif dans la réponse, en fonction du type d'erreur. De plus, le corps de la réponse contient une description détaillée de la cause de l'erreur. Voici un exemple de réponse d'erreur:

{
 "error": {
  "errors": [
   {
    "domain": "global",
    "reason": "invalidParameter",
    "message": "Invalid value '-1' for max-results. Value must be within the range: [1, 1000]",
    "locationType": "parameter",
    "location": "max-results"
   }
  ],
  "code": 400,
  "message": "Invalid value '-1' for max-results. Value must be within the range: [1, 1000]"
 }
}

Tableau d'erreurs

Code Motif Description Action recommandée
400 invalidParameter Indique qu'un paramètre de requête inclut une valeur non valide. Les champs locationType et location de la réponse d'erreur fournissent des informations sur la valeur non valide. Ne relancez pas la requête avant d'avoir résolu le problème. Vous devez fournir une valeur valide pour le paramètre spécifié dans la réponse d'erreur.
400 badRequest Indique que la requête n'était pas valide. Par exemple, l'ID parent était manquant ou la combinaison de dimensions ou de métriques demandées n'était pas valide. Ne relancez pas la requête avant d'avoir résolu le problème. Vous devez modifier la requête API pour qu'elle fonctionne.
401 invalidCredentials Indique que le jeton d'authentification n'est pas valide ou a expiré. Ne relancez pas la requête avant d'avoir résolu le problème. Vous devez obtenir un nouveau jeton d'authentification.
403 insufficientPermissions Indique que l'utilisateur ne dispose pas des autorisations suffisantes pour l'entité spécifiée dans la requête. Ne relancez pas la requête avant d'avoir résolu le problème. Vous devez obtenir les autorisations suffisantes pour effectuer l'opération sur l'entité spécifiée.
403 dailyLimitExceeded Indique que l'utilisateur a dépassé le quota quotidien (par projet ou par vue (profil). Ne relancez pas la requête avant d'avoir résolu le problème. Vous avez utilisé votre quota quotidien. Consultez Limites et quotas d'API.
403 userRateLimitExceeded Indique que la limite du nombre de requêtes pour 100 secondes par utilisateur a été dépassée. La valeur par défaut définie dans la console Google APIs est de 100 requêtes pour 100 secondes et par utilisateur. Vous pouvez augmenter cette limite dans la console Google APIs jusqu'à 1 000. Réessayez en utilisant un intervalle exponentiel entre les tentatives. Vous devez ralentir la fréquence à laquelle vous envoyez les requêtes.
403 rateLimitExceeded Indique que les limites de débit des requêtes pour 100 secondes du projet ont été dépassées. Réessayez en utilisant un intervalle exponentiel entre les tentatives. Vous devez ralentir la fréquence à laquelle vous envoyez les requêtes.
403 quotaExceeded Indique que vous avez atteint la limite de 10 requêtes simultanées par vue (profil) dans l'API Core Reporting. Réessayez en utilisant un intervalle exponentiel entre les tentatives. Vous devez attendre qu'au moins une requête en cours soit traitée pour cette vue (profil).
500 internalServerError Une erreur interne inattendue s'est produite sur le serveur. Ne relancez pas cette requête plusieurs fois.
503 backendError Le serveur a renvoyé une erreur. Ne relancez pas cette requête plusieurs fois.

Gérer les réponses 500 ou 503

Une erreur 500 ou 503 peut se produire en cas de charge importante ou de requêtes plus importantes et plus complexes. Pour les requêtes plus importantes, envisagez de demander des données pour une période plus courte. Envisagez également d'implémenter un intervalle exponentiel entre les tentatives. La fréquence de ces erreurs peut dépendre de la vue (profil) et de la quantité de données de rapport associées à cette vue. Une requête qui provoque une erreur 500 ou 503 pour une vue (profil) ne générera pas nécessairement une erreur pour la même requête avec une autre vue (profil).

Mettre en œuvre l'intervalle exponentiel entre les tentatives

L'intervalle exponentiel entre les tentatives est le processus par lequel un client relance périodiquement une requête ayant échoué sur une durée croissante. Il s'agit d'une stratégie standard de traitement des erreurs pour les applications réseau. L'API Management est conçue pour s'attendre à ce que les clients qui choisissent de relancer les requêtes ayant échoué le fassent en utilisant un intervalle exponentiel entre les tentatives. En plus d'être "obligatoire", l'intervalle exponentiel entre les tentatives augmente l'efficacité de l'utilisation de la bande passante, réduit le nombre de requêtes nécessaires pour obtenir une réponse positive et maximise le débit des requêtes dans les environnements avec simultanéité.

Le processus d'implémentation d'un intervalle exponentiel simple entre les tentatives se présente comme suit.

  1. Envoyer une requête à l'API
  2. Recevoir une réponse d'erreur avec un code d'erreur pouvant faire l'objet d'une nouvelle tentative
  3. Patientez 1 s + random_number_milliseconds secondes
  4. Réessayer la requête
  5. Recevoir une réponse d'erreur avec un code d'erreur pouvant faire l'objet d'une nouvelle tentative
  6. Patientez 2 s + random_number_milliseconds secondes
  7. Réessayer la requête
  8. Recevoir une réponse d'erreur avec un code d'erreur pouvant faire l'objet d'une nouvelle tentative
  9. Patientez 4 s + random_number_milliseconds secondes
  10. Réessayer la requête
  11. Recevoir une réponse d'erreur avec un code d'erreur pouvant faire l'objet d'une nouvelle tentative
  12. Patientez 8 s + random_number_milliseconds secondes
  13. Réessayer la requête
  14. Recevoir une réponse d'erreur avec un code d'erreur pouvant faire l'objet d'une nouvelle tentative
  15. Patientez 16 s + random_number_milliseconds secondes
  16. Réessayer la requête
  17. Si l'erreur persiste, arrêtez-la et consignez-la.

Dans le flux ci-dessus, random_number_milliseconds est un nombre aléatoire de millisecondes inférieur ou égal à 1 000. Cela est nécessaire pour éviter certaines erreurs de verrouillage dans certaines implémentations simultanées. random_number_milliseconds doit être redéfini après chaque temps d'attente.

Remarque: L'attente correspond toujours à (2 ^ n) + random_number_milliseconds, où "n" est un entier augmentant de manière monotone défini initialement sur 0. n est incrémenté de 1 pour chaque itération (chaque requête).

L'algorithme est configuré pour se terminer lorsque "n" vaut 5. Ce plafond a pour seul objectif d'empêcher les clients d'effectuer des relances indéfiniment. Il entraîne un délai total d'environ 32 secondes avant qu'une requête ne soit considérée comme une "erreur non récupérable".

Le code Python suivant est une implémentation du flux ci-dessus permettant de récupérer les erreurs survenant dans une méthode appelée makeRequest.

import random
import time
from apiclient.errors import HttpError

def makeRequestWithExponentialBackoff(analytics):
  """Wrapper to request Google Analytics data with exponential backoff.

  The makeRequest method accepts the analytics service object, makes API
  requests and returns the response. If any error occurs, the makeRequest
  method is retried using exponential backoff.

  Args:
    analytics: The analytics service object

  Returns:
    The API response from the makeRequest method.
  """
  for n in range(0, 5):
    try:
      return makeRequest(analytics)

    except HttpError, error:
      if error.resp.reason in ['userRateLimitExceeded', 'quotaExceeded',
                               'internalServerError', 'backendError']:
        time.sleep((2 ** n) + random.random())
      else:
        break

  print "There has been an error, the request never succeeded."