Le partage d'identifiants dans vos requêtes API améliore les performances et évite une surcharge excessive pouvant entraîner des erreurs de limite de débit. Ce guide explique comment optimiser la gestion des identifiants OAuth2 afin que votre application puisse interagir efficacement avec l'API Google Ads.
Votre stratégie de partage des identifiants dépendra du fait que votre application soit multithreaded ou multiprocessus (ou distribuée). Une application qui est à la fois multiprocessus et multithread dans chaque processus doit utiliser les deux stratégies. Ces stratégies peuvent également être adaptées à plusieurs comptes Google Ads.
Multithread
Chaque session ou utilisateur tiré par un thread doit utiliser le même objet d'identifiant. L'actualisation des jetons d'accès doit également être effectuée de manière synchrone afin d'éviter les conditions de concurrence.
Nos bibliothèques clientes garantissent que l'identifiant est un objet thread-safe qui s'actualise de manière synchrone lorsque son jeton d'accès expire. Chacune de nos bibliothèques clientes possède un objet de session (ou d'utilisateur) avec un identifiant qu'elle réutilise tout au long de sa durée de vie. Pour partager les identifiants entre les threads, il vous suffit de construire chaque session à l'aide des mêmes identifiants. Par exemple, dans la bibliothèque cliente Java, vous devez créer un singleton Credential et le partager entre toutes les sessions.
Multiprocessus ou distribué
Pour les processus multiprocessus ou distribués, vous devez rendre les identifiants persistants avant de pouvoir les partager. Pour vous assurer que plusieurs processus ou serveurs ne tentent pas d'actualiser les identifiants en même temps, ce qui entraînerait un nombre excessif de demandes d'actualisation, vous devez attribuer l'actualisation à un seul processus.
Par exemple, une tâche ou un service distinct peut être chargé d'actualiser régulièrement les identifiants et de les envoyer de manière proactive à un dépôt de données partagé par un pool de serveurs. Chaque serveur peut ensuite récupérer l'identifiant à partir du data store lorsqu'il effectue une requête API.
Actualiser le job
La tâche d'actualisation ne doit pas attendre l'expiration des identifiants actuels avant de lancer une actualisation. Cela peut entraîner le blocage de l'application en raison du manque d'identifiants valides. Toutefois, si le jeton d'accès d'un identifiant expire pendant le traitement de la requête API, la requête sera tout de même traitée et les résultats renvoyés.
Nous vous recommandons de suivre l'heure à laquelle votre jeton d'accès a été actualisé pour la dernière fois et de forcer une actualisation s'il reste moins de cinq minutes avant son expiration.
Si vous ne savez pas quand un jeton d'accès a été actualisé pour la dernière fois, vous pouvez essayer de l'actualiser en supposant qu'il a déjà expiré. Si le jeton d'accès n'est pas sur le point d'expirer, le serveur renvoie le même jeton d'accès, ainsi que le nombre de millisecondes restantes avant son expiration.
Datastore
Vous pouvez utiliser un magasin de données existant ou en déployer un spécifique au partage d'identifiants entre les serveurs. Les solutions incluent des serveurs de mise en cache, tels que Memcached ou Infinispan, ou des magasins de données NoSQL, tels que MongoDB.
Le data store doit être optimisé pour les opérations de lecture rapides, car il y aura beaucoup plus de requêtes de lecture que d'écritures. De plus, les identifiants doivent être stockés de manière sécurisée.
Lorsque vous stockez les identifiants, vous devez stocker les valeurs expiry_time (maintenant + expires_in) et refresh_token calculées avec access_token. Le expiry_time est calculé en ajoutant le temps de la demande d'actualisation access_token au temps expires_in.
Pool de serveurs
Chaque serveur ou processus du pool récupère les derniers identifiants du data store avant d'envoyer une requête. Tant que le job d'actualisation s'exécute correctement, les identifiants sont valides. Toutefois, si la tâche d'actualisation ou le data store échouent, vous devez disposer d'un mécanisme de secours.
Si un serveur ou un processus ne peut pas obtenir d'identifiant à partir du data store, ou si l'identifiant a expiré, le serveur doit actualiser ses propres identifiants pour permettre à l'application de continuer à fonctionner avec l'API jusqu'à ce que le problème soit résolu.
Gestion des identifiants pour plusieurs comptes
Les identifiants générés pour un compte administrateur Google Ads peuvent être utilisés pour accéder à tous ses comptes enfants. Ainsi, pour les utilisateurs disposant d'une seule hiérarchie de comptes administrateur, il suffit généralement de générer des identifiants pour le compte administrateur de premier niveau afin de les utiliser pour tous les comptes Google Ads situés en dessous.
Si votre application doit accéder à des comptes Google Ads qui ne sont pas associés les uns aux autres dans une hiérarchie de comptes administrateur, vous devez générer et gérer des identifiants différents pour chaque compte. Par exemple, pour chaque compte client Google Ads auquel vous accédez ou pour chaque compte administrateur de niveau supérieur dans les hiérarchies indépendantes auxquelles vous accédez.
Vous pouvez suivre les mêmes stratégies pour les applications multithreaded ou multiprocessus / distribuées en apportant quelques modifications mineures. Lorsque vous utilisez un data store partagé, les identifiants doivent être indexés par l'identifiant de compte customerId pour s'assurer qu'ils sont associés au bon compte.
De plus, le job d'actualisation doit actualiser tous les identifiants. Si un nouveau compte est associé, il peut être nécessaire de déclencher le job d'actualisation.
Enfin, dans les applications multithread, vous ne devez partager l'objet d'identifiant qu'entre les threads qui fonctionnent sur le compte auquel l'objet d'identifiant est associé.