Autorisation
Toutes les requêtes adressé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:
- Préparez-vous au 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 le Guide de démarrage.
- Pour accéder aux données utilisateur, l'application envoie à Google une requête pour un champ d'application d'accès particulier.
- Google affiche un écran de consentement qui invite l'utilisateur à autoriser l'application à accéder à certaines de ses données.
- Si l'utilisateur accepte, Google fournit à l'application un jeton d'accès qui expire au bout d'une courte période.
- L'application envoie une requête pour les données utilisateur en joignant le jeton d'accès à la requête.
- Dès lors que Google valide la requête et le jeton, les données demandées sont renvoyées.
Pour déterminer les champs d'application adaptés à votre application, consultez la section Champs d'application d'autorisation.
La procédure pour certains types d'applications comporte des étapes supplémentaires, comme 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 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). Utilisez les ID d'éléments multimédias et d'albums 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 devez actualiser de nombreux éléments multimédias, 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 recharger les données.
Accès SSL
HTTPS est requis pour toutes les requêtes de service Web des API Photos 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 savoir comment gérer les erreurs renvoyées par l'API, consultez la section Gérer les erreurs des API Cloud.
Réessayer les requêtes ayant échoué
Les clients doivent effectuer de nouvelles tentatives suite aux 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 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 réessayer la 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. En règle générale, le délai est augmenté d'un facteur multiplicatif à chaque tentative, une approche appelée intervalle exponentiel 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.
Utilisation polie des API Google
Les clients d'API mal conçus peuvent générer une charge plus importante que nécessaire à la fois sur Internet et sur les serveurs de Google. Cette section contient quelques bonnes pratiques pour 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 envoyées aux API de Google peuvent ressembler à une attaque par déni de service distribué (DDoS) sur l'infrastructure de Google et être traitées 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 la zone horaire actuelle. Cette application définira probablement une alarme dans le système d'exploitation client pour le réveiller au début de la minute afin que l'heure affichée puisse être mise à 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 son affichage au début de la minute, l'application utilise les résultats précédemment stockés plutôt que 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 lorsque l'écran est mis à jour.
En plus du début de la minute, d'autres heures de synchronisation courantes que vous devez éviter de cibler sont le début d'une heure et le début de chaque jour à minuit.