Compartir credenciales entre tus solicitudes a la API mejora el rendimiento y evita una sobrecarga excesiva que puede generar errores de límite de frecuencia. En esta guía, se explica cómo optimizar la administración de credenciales de OAuth2 para que tu app pueda interactuar de manera eficiente con la API de Google Ads.
La estrategia de uso compartido de credenciales dependerá de si tu app es multiproceso o multiproceso (o distribuido). Una app que posee varios procesos y varios subprocesos dentro de cada proceso debe usar ambas estrategias. Estas estrategias también se pueden adaptar para varias cuentas de Google Ads.
Varios subprocesos
Cada sesión o usuario que dibuje un subproceso debe usar el mismo objeto de credencial. Las actualizaciones de tokens de acceso también deben realizarse de forma síncrona para evitar condiciones de carrera.
Nuestras bibliotecas cliente garantizan que la credencial sea un objeto seguro para los subprocesos que se actualice de forma síncrona cuando vence el token de acceso. Cada una de nuestras bibliotecas cliente tiene un objeto de sesión (o de usuario) con una credencial que reutiliza a lo largo de su vida útil. Para compartir la credencial entre subprocesos, solo debes construir cada sesión con la misma credencial. Por ejemplo, en la biblioteca cliente de Java, deberías crear un singleton Credential y compartirlo en todas las sesiones.
Multiproceso o distribuido
En el caso de procesos distribuidos o de varios procesos, debes conservar la credencial antes de poder compartirla. Para garantizar que varios procesos o servidores no intenten actualizar la credencial al mismo tiempo, lo que genera solicitudes de actualización excesivas, debes asignar la actualización a un solo proceso.
Por ejemplo, un trabajo o servicio independiente puede ser responsable de actualizar la credencial de forma periódica y enviarla de manera proactiva a un almacén de datos compartido por un grupo de servidores. Luego, cada servidor puede recuperar la credencial del almacén de datos cuando realiza una solicitud a la API.
Actualizar trabajo
El trabajo de actualización no debe esperar a que venza la credencial actual antes de iniciar una actualización. Si lo haces, es posible que la app se detenga debido a la falta de una credencial válida. Sin embargo, si el token de acceso de una credencial vence mientras se procesa la solicitud a la API, la solicitud aún se completará y se mostrarán los resultados.
Te recomendamos que realices un seguimiento de la hora a la que se actualizó por última vez el token de acceso y que fuerces una actualización si faltan menos de 5 minutos para que venza.
Si no sabes cuándo se actualizó por última vez un token de acceso, puedes intentar actualizarlo si ya venció. Si el token de acceso no está a punto de caducar, el servidor muestra el mismo token de acceso, junto con los milisegundos restantes hasta que venza.
Almacén de datos
Puedes usar un almacén de datos existente o implementar uno específico para el uso compartido de credenciales entre servidores. Las soluciones incluyen servidores de almacenamiento en caché, como Memcached o Infinispan, o almacenes de datos NoSQL, como MongoDB.
El almacén de datos debe optimizarse para las operaciones de lectura rápida, ya que habrá muchas más solicitudes de lectura que escrituras. Además, las credenciales se deben almacenar de forma segura.
Cuando almacenes la credencial, debes almacenar el expiry_time calculado (ahora + expires_in) y el refresh_token junto con el access_token. El expiry_time se calcula como la hora de la solicitud de actualización de access_token más el tiempo de expires_in.
Grupo de servidores
Cada servidor o proceso del grupo recupera la credencial más reciente del almacén de datos antes de realizar una solicitud. Siempre que el trabajo de actualización se ejecute correctamente, la credencial será válida. Sin embargo, si el trabajo de actualización o el almacén de datos fallan, deberías tener un mecanismo de resguardo.
Si un servidor o proceso no puede obtener una credencial del almacén de datos, o si la credencial caducó, el servidor debe actualizar sus propias credenciales para permitir que la app siga trabajando con la API hasta que se resuelva el problema.
Administración de credenciales para varias cuentas
Se puede utilizar una credencial generada para una cuenta de administrador de Google Ads para acceder a todas sus cuentas secundarias. Por lo tanto, en el caso de los usuarios con una sola jerarquía de la cuenta de administrador, suele ser suficiente generar una credencial para la cuenta de administrador de nivel superior que se usará en todas las cuentas de Google Ads inferiores.
Si tu app necesita acceder a cuentas de Google Ads que no están relacionadas entre sí en ninguna jerarquía de la cuenta de administrador, debes generar y mantener credenciales diferentes para cuentas distintas, por ejemplo, para cada cuenta de cliente de Google Ads a la que accedes o cada cuenta de administrador de nivel superior en las jerarquías independientes a las que accedes.
Puedes seguir las mismas estrategias para las apps multisubproceso o
multiproceso o distribuido con pequeñas modificaciones. Cuando se usa un almacén de datos compartido, el identificador de cuenta customerId debe indexar las credenciales para garantizar que las credenciales estén asociadas con la cuenta correcta.
Además, el trabajo de actualización debe mantener todas las credenciales actualizadas. Si se vincula una cuenta nueva, es posible que se deba activar el trabajo de actualización.
Por último, en las apps con varios subprocesos, solo debes compartir el objeto de credencial entre los subprocesos que operan en la cuenta con la que está asociado el objeto de credencial.