Compartir credenciales en tus solicitudes a la API mejora el rendimiento y evita la sobrecarga excesiva que puede generar errores en el 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 la app es multiproceso o multiproceso (o distribuida). Una app que tenga varios procesos y varios subprocesos dentro de cada proceso debería emplear ambas estrategias. Estas estrategias también se pueden adaptar para varias cuentas de Google Ads.
Varios subprocesos
Cada sesión o usuario que genera 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 subprocesos que se actualiza de forma síncrona cuando vence su token de acceso. Cada una de nuestras bibliotecas cliente tiene un objeto de sesión (o usuario) con una credencial que reutiliza durante su ciclo de vida. Para compartir la credencial entre subprocesos, solo debes crear cada sesión con la misma credencial. Por ejemplo, en la biblioteca cliente de Java, debes crear un singleton Credential y compartirlo en todas las sesiones.
Multiproceso o distribuido
En el caso de los procesos distribuidos o de varios procesos, debes conservar la credencial antes de poder compartirla. Para asegurarte de que varios procesos o servidores no intenten actualizar la credencial al mismo tiempo, lo que genera demasiadas solicitudes de actualización, debes asignar la actualización a un solo proceso.
Por ejemplo, un trabajo o servicio separado puede ser responsable de actualizar periódicamente la credencial y enviarla de forma proactiva a un almacén de datos compartido por un grupo de servidores. 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 debería esperar hasta que caduque la credencial actual para iniciar una actualización. Esto podría provocar que la app se detenga por 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 se completará y se mostrarán los resultados.
Te recomendamos realizar un seguimiento de la hora en la que se actualizó el token de acceso por última vez y forzar una actualización si faltan menos de 5 minutos para el vencimiento.
Si no sabes cuándo se actualizó un token de acceso por última vez, puedes intentar actualizarlo suponiendo que ya venció. Si el token de acceso no está a punto de caducar, el servidor muestra el mismo token de acceso y los milisegundos restantes hasta que el token 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 debería optimizarse para 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 refresh_token junto con access_token. expiry_time se calcula como el tiempo 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 falla el trabajo de actualización o el almacén de datos, debes tener un mecanismo de resguardo.
Si un servidor o proceso no puede obtener una credencial del almacén de datos, o si la credencial venció, el servidor debe actualizar sus propias credenciales para permitir que la app continúe trabajando con la API hasta que se resuelva el problema.
Administración de credenciales para varias cuentas
Una credencial generada para una cuenta de administrador de Google Ads se puede usar para acceder a todas sus cuentas secundarias. Por lo tanto, en el caso de los usuarios con una sola jerarquía de cuenta de administrador, suele ser suficiente generar una credencial para que la cuenta de administrador de nivel superior se use 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 cuentas de administrador, debes generar y mantener diferentes credenciales para diferentes cuentas, por ejemplo, para cada cuenta de cliente de Google Ads a la que accedas o cada cuenta de administrador de nivel superior en las jerarquías independientes a las que accedas.
Puedes seguir las mismas estrategias para apps de varios subprocesos o multiproceso o distribuida con pequeñas modificaciones. Cuando se usa un almacén de datos compartido, las credenciales deben indexarse con el identificador de cuenta customerId para garantizar que las credenciales se asocien 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.