Le partage des identifiants entre vos requêtes API améliore les performances et évite les frais généraux excessifs pouvant entraîner des erreurs de limitation du 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 session (ou utilisateur) avec des identifiants qu'elle réutilise tout au long de sa durée de vie. Pour partager les identifiants entre threads, il vous suffit de construire chaque session à l'aide des mêmes identifiants. 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 l'identifiant avant de pouvoir le partager. Pour vous assurer que plusieurs processus ou serveurs n'essaient pas d'actualiser les identifiants en même temps, ce qui entraîne un nombre excessif de requêtes d'actualisation, vous devez affecter l'actualisation à un seul processus.
Par exemple, une tâche ou un service distincts peuvent se charger d'actualiser régulièrement les identifiants et de les transférer 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'envoi d'une requête API.
Actualiser le job
La tâche d'actualisation ne doit pas attendre que les identifiants actuels expirent pour lancer une actualisation. Cela peut entraîner le blocage de l'application en raison de 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 terminera et les résultats seront 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 l'actualisation si le délai d'expiration est inférieur à cinq minutes.
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 proche de l'expiration, le serveur renvoie le même jeton d'accès, ainsi que les millisecondes restantes avant l'expiration du jeton.
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 des serveurs de mise en cache, tels que Memcached ou Infinispan, ou des datastores 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 calculées expiry_time (maintenant + expires_in) et refresh_token avec access_token. expiry_time correspond à l'heure de la requête d'actualisation access_token plus l'heure du expires_in.
Pool de serveurs
Chaque serveur ou processus du pool récupère les derniers identifiants du magasin de données avant d'effectuer 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 datastore échoue, vous devriez disposer d'un mécanisme de secours.
Si un serveur ou un processus ne peut pas obtenir d'identifiant à partir 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 peuvent être utilisés pour accéder à tous ses comptes enfants. Ainsi, pour les utilisateurs disposant d'une hiérarchie de comptes administrateur unique, il suffit généralement de générer des identifiants pour le compte administrateur de niveau supérieur à utiliser pour tous les comptes Google Ads inférieurs à celui-ci.
Si votre application doit accéder à des comptes Google Ads qui ne sont pas liés entre eux dans une hiérarchie de comptes administrateur, vous devez générer et gérer des identifiants différents pour les différents comptes (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 multithread ou multiprocessus / distribuées, avec des modifications mineures. Lorsque vous utilisez un data store partagé, les identifiants doivent être indexés selon l'identifiant de compte customerId pour s'assurer que les identifiants sont associés au bon compte.
De plus, le job d'actualisation doit maintenir tous les identifiants à jour. Si un nouveau compte est associé, vous devrez peut-être déclencher la tâche d'actualisation.
Enfin, dans les applications multithread, vous ne devez partager l'objet d'identification qu'entre les threads qui s'exécutent sur le compte auquel l'objet d'identification est associé.