Le partage d'identifiants entre vos requêtes API améliore les performances et évite une surcharge excessive qui peut 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 d'identifiants varie selon que votre application est multithread ou multiprocessus (ou distribuée). Une application 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 dessiné par un thread doit utiliser le même objet d'identification. Les actualisations de jetons d'accès doivent également être effectuées 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 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 du même identifiant. Par exemple, dans la bibliothèque cliente Java, vous pouvez créer un singleton Credential et le partager entre toutes les sessions.
Multiprocessus ou distribué
Pour les processus multiprocessus ou distribués, vous devez conserver les identifiants 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îne un nombre excessif de requêtes d'actualisation, vous devez attribuer l'actualisation à un seul processus.
Par exemple, une tâche ou un service distinct peut être responsable de l'actualisation périodique des identifiants et de leur transfert de manière proactive vers un datastore partagé par un pool de serveurs. Chaque serveur peut ensuite récupérer les identifiants du magasin de données lors de l’exécution d’une requête API.
Actualiser le job
La tâche d'actualisation ne doit pas attendre l'expiration de l'identifiant actuel pour lancer une actualisation. Cela peut entraîner le blocage de l'application en l'absence d'identifiants valides. Toutefois, si le jeton d'accès d'un identifiant expire pendant le traitement de la requête API, celle-ci se termine, et les résultats sont renvoyés.
Nous vous recommandons de garder une trace de l'heure à laquelle votre jeton d'accès a été actualisé pour la dernière fois et de forcer l'actualisation s'il reste moins de cinq minutes avant l'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 est proche de l'expiration, le serveur renvoie le même jeton d'accès, ainsi que les millisecondes restantes avant son expiration.
Datastore
Vous pouvez utiliser un data store existant ou en déployer un spécifique au partage d'identifiants entre les serveurs. Les solutions incluent la mise en cache de serveurs, tels que Memcached ou Infinispan, ou les 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'écriture. En outre, les identifiants doivent être stockés de manière sécurisée.
Lorsque vous stockez les identifiants, vous devez stocker les valeurs expiry_time calculées (désormais + expires_in) et refresh_token avec access_token. La valeur expiry_time est calculée en additionnant l'heure de la requête d'actualisation access_token et la durée de expires_in.
Pool de serveurs
Chaque serveur ou processus du pool récupère les derniers identifiants du datastore avant d'envoyer une requête. Tant que la tâche d'actualisation s'exécute correctement, l'identifiant est valide. Toutefois, en cas d'échec de la tâche d'actualisation ou du datastore, vous devez disposer d'un mécanisme de secours.
Si un serveur ou un processus ne peut pas obtenir d'identifiants auprès du datastore ou si les identifiants ont expiré, le serveur doit actualiser ses propres identifiants pour permettre à l'application de continuer à utiliser 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 permettent d'accéder à tous ses comptes enfants. Ainsi, pour les utilisateurs disposant d'une hiérarchie de compte administrateur unique, il est généralement suffisant de générer des identifiants pour le compte administrateur de niveau supérieur à utiliser pour tous les comptes Google Ads de niveau inférieur.
Si votre application doit accéder à des comptes Google Ads qui ne sont pas liés les uns aux autres dans une hiérarchie de compte administrateur, vous devez générer et gérer des identifiants différents pour chaque compte 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 multithread ou multiprocessus / distribuées, avec des modifications mineures. Lorsque vous utilisez un data store partagé, les identifiants doivent être indexés par l'identifiant de compte customerId pour garantir que les identifiants sont associés au bon compte.
De plus, la tâche d'actualisation doit s'assurer que tous les identifiants sont actualisés. Si un nouveau compte est associé, la tâche d'actualisation devra peut-être être déclenchée.
Enfin, dans les applications multithread, vous ne devez partager l'objet d'identification qu'entre les threads qui opèrent sur le compte auquel il est associé.