Autorisation
Toutes les requêtes adressées à l'API Library de Google Photos doivent être autorisées par un utilisateur authentifié.
Les détails de la procédure d'autorisation pour OAuth 2.0 varient légèrement selon sur le type d'application que vous écrivez. La procédure générale suivante s'applique à tous les types d'applications:
- Préparez le processus d'autorisation en procédant comme suit:
<ph type="x-smartling-placeholder">
- </ph>
- Enregistrez votre application à l'aide de la méthode Console Google APIs
- Activez l'API Library et récupérez les détails OAuth tels que et un code secret du client. Pour en savoir plus, consultez Commencer
- Pour accéder aux données utilisateur, l'application demande à Google un niveau d'accès particulier.
- Google présente à l'utilisateur un écran de consentement qui l'invite à autoriser l'accès pour demander certaines de ses données.
- Si l'utilisateur accepte, Google fournit un jeton d'accès à l'application. qui expirent après une brève période de temps.
- L'application envoie une requête pour récupérer les données utilisateur, en joignant le jeton d'accès à la demande.
- 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 pour différents types d'applications, consultez la page Using OAuth 2.0 to Access Google API.
Mise en cache
Maintenir les données à jour.
Si vous avez besoin de stocker temporairement des contenus multimédias (comme des vignettes, des photos ou des vidéos) pour des raisons de performances, ne le mettez pas en cache pendant plus de 60 minutes consignes.
Vous ne devez pas non plus stocker baseUrls, qui expire après environ 60 jours
minutes.
ID d'éléments multimédias et d'albums 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). 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 Pour en savoir plus, consultez la section Obtenir un fichier item ou Fiche 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 de l'API Library 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.
Relancer 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 avec un délai minimal de 30s. Pour toutes les autres
erreurs, il est possible que vous ne puissiez pas réessayer. Assurez-vous que votre requête est idempotente et examinez
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 demande.
le code de réponse HTTP 4XX ou 5XX, ou la connexion TCP peut échouer quelque part
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 les boucler et d'envoyer
des requêtes à plusieurs reprises aux serveurs de Google. Ce
le comportement en boucle peut surcharger le réseau entre votre client et Google et
causer des problèmes à
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 veiller à ce qu'il n'y ait pas de code de nouvelle tentative plus haut dans l'application d'appel qui conduit à des requêtes répétées en succession rapide.
Bon usage des API Google
Les clients API mal conçus peuvent placer plus de charge que nécessaire sur les deux 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 les application 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 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 effectuer aucun appel d'API lors du traitement associées à cette alarme.
Effectuer des appels d'API en réponse à une alarme fixe n'est pas une bonne chose, car cela entraîne le les appels d'API sont synchronisés en début de minute, même entre différents d'appareils, au lieu d'être répartis uniformément au fil du temps. Une application mal conçue l'application génère un pic de trafic 60 fois supérieur à la normale. au début de chaque minute.
Une bonne conception consiste plutôt à définir une deuxième alarme définie sur un paramètre l'heure choisie. Lorsque cette seconde alarme se déclenche, l'application appelle dont il 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.