Bonnes pratiques

Autorisation

Toutes les requêtes envoyées aux API Google Photos doivent être autorisées par un utilisateur authentifié.

Les détails du processus d'autorisation pour OAuth 2.0 varient légèrement selon le type d'application que vous développez. La procédure générale suivante s'applique à tous les types d'applications:

  1. Préparez le processus d'autorisation en procédant comme suit:
    • Enregistrez votre application à l'aide de la console Google APIs.
    • Activez les API Photos et récupérez des informations OAuth telles qu'un ID client et un code secret client. Pour en savoir plus, consultez Commencer
  2. Pour accéder aux données utilisateur, l'application demande à Google un niveau d'accès particulier.
  3. Google affiche un écran de consentement qui invite l'utilisateur à autoriser l'application à accéder à certaines de ses données.
  4. Si l'utilisateur accepte, Google fournit à l'application un jeton d'accès qui expire au bout d'une courte période.
  5. L'application envoie une requête pour récupérer les données utilisateur, en joignant le jeton d'accès à la demande.
  6. Si Google détermine que la requête et le jeton sont valides, il renvoie la les données demandées.

Pour déterminer les champs d'application adaptés à votre application, consultez la section Informations sur les autorisations champs d'application.

Pour certains types d'applications, le processus comprend des étapes supplémentaires, telles que l'utilisation actualiser des jetons pour obtenir de nouveaux jetons d'accès. Pour en savoir plus sur les flux pour différents types d'applications, consultez Utiliser OAuth 2.0 pour accéder aux API Google.

Mise en cache

Actualisez régulièrement vos données.

Si vous devez stocker temporairement des contenus multimédias (tels que des miniatures, des photos ou des vidéos) pour des raisons de performances, ne les mettez pas en cache pendant plus de 60 minutes, conformément à nos consignes d'utilisation.

Vous ne devez pas non plus stocker baseUrls, qui expire au bout d'environ 60 minutes.

Les ID d'éléments multimédias et d'albums qui identifient de manière unique le contenu de la bibliothèque d'un utilisateur ne sont pas soumis à la restriction de mise en cache. Vous pouvez stocker ces ID indéfiniment (sous réserve des règles de confidentialité de votre application). Utiliser les ID des éléments multimédias et des albums pour récupérer à nouveau les URL et les données accessibles en utilisant les points de terminaison appropriés. Pour en savoir plus, consultez Obtenir un élément multimédia ou Lister des albums.

Si vous avez de nombreux éléments multimédias à actualiser, il peut être plus efficace de stocker le fichier Paramètres de recherche qui ont renvoyé les éléments multimédias, puis renvoyez la requête pour actualiser données.

Accès SSL

HTTPS est requis pour toutes les requêtes de service Web des API Photos utilisant le URL suivante:

https://photoslibrary.googleapis.com/v1/service/output?parameters

Les requêtes effectuées via HTTP sont rejetées.

Gestion des exceptions

Pour en savoir plus sur la gestion des erreurs renvoyées par l'API, consultez la documentation API Gestion erreurs.

Réessayer les requêtes ayant échoué

Les clients doivent effectuer de nouvelles tentatives en cas d'erreurs 5xx avec un intervalle exponentiel entre les tentatives, comme décrit dans Intervalle exponentiel entre les tentatives. Le délai minimal doit être de 1 s sauf indication contraire.

Pour les erreurs 429, le client peut réessayer en respectant un délai minimal de 30s. Pour toutes les autres erreurs, il se peut que la nouvelle tentative ne s'applique pas. Assurez-vous que votre requête est idempotente et consultez le message d'erreur pour obtenir des conseils.

Intervalle exponentiel entre les tentatives

Dans de rares cas, un problème peut survenir lors du traitement de votre requête. Vous pouvez recevoir un code de réponse HTTP 4XX ou 5XX, ou la connexion TCP peut échouer entre votre client et le serveur de Google. Il est souvent utile de relancer requête. La requête de suivi peut aboutir alors que la requête d'origine a échoué. Toutefois, il est important de ne pas effectuer de boucles en envoyant des requêtes répétées aux serveurs de Google. Ce comportement en boucle peut surcharger le réseau entre votre client et Google, et causer des problèmes pour de nombreuses parties.

Il est préférable de réessayer en allongeant progressivement les délais entre deux tentatives. Habituellement, le délai est augmenté d'un facteur multiplicatif à chaque tentative, une approche Exponentielle entre les tentatives.

Vous devez également vous assurer qu'il n'y a pas de code de nouvelle tentative plus haut dans la chaîne d'appels de l'application qui entraîne des requêtes répétées en succession rapide.

Bon usage des API Google

Les clients d'API mal conçus peuvent générer une charge plus importante que nécessaire sur Internet et sur les serveurs de Google. Cette section contient des bonnes pratiques les clients des API. Le respect de ces bonnes pratiques peut vous aider à éviter que votre application ne soit bloquée en raison d'un usage abusif involontaire des API.

Requêtes synchrones

Un grand nombre de requêtes synchronisées vers les API Google peut ressembler à une attaque par déni de service distribué (DDoS) sur l'infrastructure de Google sont traitées en conséquence. Pour éviter cela, vous devez vous assurer que les requêtes API sont non synchronisés entre les clients.

Prenons l'exemple d'une application qui affiche l'heure actuelle à l'heure actuelle. dans la zone. Cette application définira probablement une alarme dans le système d'exploitation client au début de la minute pour que l'heure affichée puisse être mis à jour. L'application ne doit pas effectuer d'appels d'API dans le cadre du traitement associé à cette alarme.

Effectuer des appels d'API en réponse à une alarme fixe est une mauvaise pratique, car les appels d'API sont synchronisés au début de la minute, même entre différents appareils, au lieu d'être répartis uniformément au fil du temps. Une application mal conçue qui procède ainsi génère un pic de trafic 60 fois supérieur aux niveaux normaux au début de chaque minute.

Une bonne conception consiste plutôt à définir une deuxième alarme à une heure choisie de manière aléatoire. Lorsque cette deuxième alarme se déclenche, l'application appelle toutes les API dont elle a besoin et stocke les résultats. Pour mettre à jour l'affichage minute, l'application utilise les résultats précédemment stockés au lieu d'appeler la méthode de l'API. Avec cette méthode, les appels d'API sont répartis uniformément dans le temps. En outre, les appels d'API ne retardent pas l'affichage lors de la mise à jour de l'affichage.

Outre le début de la minute, vous pouvez également définir d'autres moments veillez à ne pas cibler le début d'une heure chaque jour à minuit.