Réponses d'erreur

Cette page liste les erreurs que vous pouvez recevoir de l'API User Deletion, et explique comment gérer les erreurs 500 et implémenter un intervalle exponentiel entre les tentatives.

Réponses d'erreur standards

Si une requête API de suppression d'utilisateur aboutit, l'API renvoie un code d'état 200. Si une erreur se produit avec une requête, l'API renvoie un code d'état HTTP, un état et une raison 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]" } }

Table 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'est pas valide. Par exemple, l'ID parent était manquant ou la combinaison de dimensions ou de métriques demandée n'était pas valide. Ne relancez pas la requête avant d'avoir résolu le problème. Vous devez modifier la requête de l'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 nécessaires 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 disposer d'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 la page Limites et quotas de l'API.
403 userRateLimitExceeded Indique que la limite de requêtes par 100 secondes et par utilisateur a été dépassée. La valeur par défaut définie dans la console Google API est de 100 requêtes toutes les 100 secondes par utilisateur. Vous pouvez augmenter cette limite dans la console Google APIs jusqu'à 1 000. Relancez la requête à l'aide d'un intervalle exponentiel entre les tentatives. Vous devez ralentir le débit d'envoi des requêtes.
403 rateLimitExceeded Indique que les limites de débit des requêtes par 100 secondes du projet ont été dépassées. Relancez la requête à l'aide d'un intervalle exponentiel entre les tentatives. Vous devez ralentir le débit d'envoi des requêtes.
403 quotaExceeded Indique que la limite de 10 requêtes simultanées par vue (profil) dans l'API principale de création de rapports a été atteinte. Relancez la requête avec un intervalle exponentiel entre les tentatives. Vous devez attendre qu'au moins une requête en cours pour cette vue (profil) soit terminée.
500 internalServerError Une erreur de serveur interne inattendue s'est produite. Ne relancez pas cette requête plus d'une fois.
503 backendError Le serveur a renvoyé une erreur. Ne relancez pas cette requête plus d'une fois.

Gérer les réponses 500 ou 503

Une erreur 500 ou 503 peut se produire lors d'une charge importante ou pour des requêtes plus volumineuses plus complexes. Pour les requêtes plus volumineuses, 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) n'entraîne pas nécessairement une erreur pour la même requête avec une vue (profil) différente.

Implémenter un 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 User Deletion est conçue en supposant que les clients qui choisissent de relancer les requêtes ayant échoué le font à l'aide d'un intervalle exponentiel entre les tentatives. En plus d'être "obligatoire", l'utilisation de 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 optimise le débit des requêtes dans les environnements avec simultanéité.

Voici comment mettre en œuvre l'intervalle exponentiel entre les tentatives:

  1. Vous envoyez une requête à l'API.
  2. Vous recevez 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éessayez d'envoyer la requête.
  5. Recevoir une réponse d'erreur avec un code d'erreur avec possibilité de nouvelles tentatives
  6. Patientez 2 secondes + random_number_milliseconds secondes.
  7. Réessayer la requête.
  8. Recevoir une réponse d'erreur avec un code d'erreur avec possibilité de nouvelles tentatives
  9. Patientez 4 s + random_number_milliseconds secondes.
  10. Réessayez d'envoyer la requête.
  11. Recevoir une réponse d'erreur avec un code d'erreur avec possibilité de nouvelles tentatives
  12. Patientez 8 s + random_number_milliseconds secondes.
  13. Réessayez d'envoyer la requête.
  14. Recevoir une réponse d'erreur avec un code d'erreur avec possibilité de nouvelles tentatives
  15. Patientez 16 secondes + random_number_milliseconds secondes.
  16. Réessayer la requête.
  17. Si l'erreur persiste, arrêtez-vous et consignez-la.

Dans le flux précédent, random_number_milliseconds correspond à 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.

L'algorithme est configuré pour se terminer lorsque "n" vaut 5. Ce plafond n'est mis en place que pour empêcher les clients d'effectuer des relances indéfiniment et 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 précédent pour la récupération des erreurs qui se produisent 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."