L'autorisation
Toutes les requêtes adressées à l'API Google Photos Library 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. Le processus général suivant s'applique à tous les types d'applications:
- Préparez le processus d'autorisation en procédant comme suit :
- Enregistrez votre application à l'aide de la console Google APIs.
- Activez l'API Library et récupérez les détails OAuth, tels qu'un ID client et un code secret du client. Pour en savoir plus, consultez Premiers pas.
- Pour accéder aux données utilisateur, l'application demande à Google un champ d'application particulier.
- Google affiche un écran de consentement à l'utilisateur, qui lui demande d'autoriser l'application à demander certaines de ses données.
- Si l'utilisateur accepte, Google fournit à l'application un jeton d'accès qui expire après une courte période.
- L'application envoie une requête pour obtenir les données utilisateur, en associant le jeton d'accès à la requête.
- Si Google détermine que la requête et le jeton sont valides, il renvoie les données demandées.
Pour déterminer les champs d'application adaptés à votre application, consultez la section Champs d'application des autorisations.
Pour certains types d'applications, le processus comprend des étapes supplémentaires, telles que l'utilisation de jetons d'actualisation pour obtenir de nouveaux jetons d'accès. Pour en savoir plus sur les flux pour différents types d'applications, consultez la page 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 vignettes, 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 de baseUrls, qui expirent après environ 60 minutes.
Les ID d'élément multimédia et d'album qui identifient de manière unique le contenu de la bibliothèque d'un utilisateur sont exemptés de la restriction de mise en cache. Vous pouvez stocker ces ID indéfiniment (sous réserve des règles de confidentialité de votre application). Utilisez les ID d'élément multimédia et les ID d'album pour récupérer à nouveau les URL et les données accessibles à l'aide des 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 les paramètres de recherche qui ont renvoyé les éléments multimédias et de renvoyer la requête pour actualiser les données.
Accès SSL
HTTPS est requis pour toutes les requêtes de service Web de l'API Library utilisant l'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 page Gérer les erreurs de l'API Cloud.
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 la section Intervalle exponentiel entre les tentatives. Le délai minimal doit être 1 s, sauf indication contraire.
Pour les erreurs 429, le client peut effectuer de nouvelles tentatives avec un délai minimal de 30s. Pour toutes les autres erreurs, la nouvelle tentative peut ne pas être applicable. Assurez-vous que votre requête est idempotente et consultez le message d'erreur pour en savoir plus.
Intervalle exponentiel entre les tentatives
Dans de rares cas, il peut y avoir un problème 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 la requête. La requête de suivi peut aboutir alors que la requête d'origine a échoué. Cependant, il est important de ne pas envoyer des requêtes en boucle aux serveurs de Google de manière répétée. 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. En général, le délai est augmenté selon un facteur multiplicatif à chaque tentative, ce que l'on appelle un intervalle exponentiel entre les tentatives.
Vous devez également veiller à ce qu'il n'y ait pas de code de nouvelle tentative plus haut dans la chaîne d'appel de l'application, ce qui entraînerait des requêtes répétées à succession rapide.
Utilisation respectueuse des API Google
Les clients API mal conçus peuvent placer plus de charge que nécessaire sur Internet et sur les serveurs de Google. Cette section présente certaines bonnes pratiques à l'attention des clients des API. Le respect de ces bonnes pratiques peut vous aider à éviter que votre application soit bloquée en raison d'une utilisation abusive accidentelle des API.
Requêtes synchronisées
Un grand nombre de requêtes synchronisées vers les API Google peuvent ressembler à une attaque par déni de service distribué (DDoS) sur l'infrastructure de Google. Ils peuvent être traités en conséquence. Pour éviter cela, vous devez vous assurer que les requêtes API ne sont pas synchronisées entre les clients.
Prenons l'exemple d'une application qui affiche l'heure dans le fuseau horaire actuel. Cette application définira probablement une alarme dans le système d'exploitation client pour la réveiller au début de la minute, afin que l'heure affichée puisse être mise à jour. L'application ne doit effectuer aucun appel d'API dans le cadre du traitement associé à cette alarme.
Il n'est pas recommandé d'effectuer des appels d'API en réponse à une alarme fixe, 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 dans le temps. Une application mal conçue qui effectue cette opération génère un pic de trafic 60 fois supérieur à la normale au début de chaque minute.
À la place, une deuxième alarme peut être définie sur une heure choisie au hasard. Lorsque cette deuxième alarme se déclenche, l'application appelle les API dont elle a besoin et stocke les résultats. Pour mettre à jour son affichage au début de la minute, l'application utilise les résultats stockés précédemment au lieu d'appeler à nouveau l'API. Avec cette méthode, les appels d'API sont répartis uniformément dans le temps. De plus, les appels d'API ne retardent pas le rendu lors de la mise à jour de l'écran.
Hormis le début de la minute, les heures de synchronisation courantes que vous devez éviter de cibler sont le début d'une heure et le début de chaque journée à minuit.