La condivisione delle credenziali tra le richieste API migliora le prestazioni ed evita un sovraccarico eccessivo che può causare errori di limitazione di frequenza. Questa guida spiega come ottimizzare la gestione delle credenziali OAuth2 in modo che la tua app possa interagire in modo efficiente con l'API Google Ads.
La strategia di condivisione delle credenziali dipenderà dal fatto che la tua app sia multithread o multiprocess (o distribuita). Un'app sia multiprocesso che multithread all'interno di ciascun processo dovrebbe utilizzare entrambe le strategie. Queste strategie possono essere adattate anche per più account Google Ads.
a più thread
Ogni sessione o utente tracciato da un thread deve utilizzare lo stesso oggetto credenziali. Anche gli aggiornamenti dei token di accesso devono essere eseguiti in modo sincrono per evitare le condizioni di gara.
Le nostre librerie client assicurano che la credenziale sia un oggetto thread-safe che si aggiorna in modo sincrono alla scadenza del relativo token di accesso. Ognuna delle nostre
librerie client ha un oggetto sessione (o utente) con una credenziale che riutilizza
per tutta la sua durata. Per condividere le credenziali tra i thread, costruire ogni sessione usando le stesse credenziali. Ad esempio, nella libreria client Java, devi creare un singleton Credential e condividerlo in tutte le sessioni.
Multiprocesso o distribuito
Per i processi multiprocesso o distribuiti, devi mantenere la credenziale prima di poterla condividere. Per assicurarti che più processi o server non tentano di aggiornare contemporaneamente le credenziali, causando richieste di aggiornamento eccessive, devi assegnare l'aggiornamento a un singolo processo.
Ad esempio, un job o un servizio separato può essere responsabile dell'aggiornamento periodico della credenziale e del suo push proattivo a un datastore condiviso da un pool di server. Ogni server può quindi recuperare la credenziale dal datastore quando effettua una richiesta API.
Aggiorna job
Il job di aggiornamento non deve attendere la scadenza della credenziale attuale prima di avviare un aggiornamento. In questo modo l'app potrebbe bloccarsi per mancanza di una credenziale valida. Tuttavia, se il token di accesso di una credenziale scade durante l'elaborazione della richiesta API, la richiesta verrà comunque completata e i risultati verranno restituiti.
Ti consigliamo di tenere traccia della data dell'ultimo aggiornamento del token di accesso e di forzare l'aggiornamento se mancano meno di 5 minuti alla scadenza.
Se non sai quando è stato aggiornato l'ultima volta un token di accesso, puoi tentare di aggiornarlo supponendo che sia già scaduto. Se il token di accesso non sta per scadere, il server restituisce lo stesso token di accesso, insieme ai millisecondi rimanenti fino alla scadenza del token.
Datastore
Puoi utilizzare un datastore esistente o implementarne uno specifico per la condivisione delle credenziali tra i server. Le soluzioni includono server di memorizzazione nella cache come Memcached o Infinispan oppure datastore NoSQL come MongoDB.
Il datastore dovrebbe essere ottimizzato per operazioni di lettura rapida poiché ci saranno molte più richieste di lettura che scritture. Le credenziali devono essere archiviate in modo sicuro.
Quando archivi la credenziale, devi archiviare expiry_time
(ora + expires_in) e refresh_token insieme a access_token. Il expiry_time viene calcolato come l'ora della richiesta di aggiornamento di access_token più il tempo expires_in.
Pool di server
Ogni server o processo nel pool recupera la credenziale più recente dal datastore prima di effettuare una richiesta. Se il job di aggiornamento viene eseguito correttamente, la credenziale sarà valida. Tuttavia, se il job di aggiornamento o il datastore non va a buon fine, dovresti avere un meccanismo di fallback.
Se un server o un processo non riesce a ottenere una credenziale dal datastore o se la credenziali è scaduta, il server deve aggiornare le proprie credenziali per consentire all'app di continuare a utilizzare l'API fino alla risoluzione del problema.
Gestione delle credenziali per più account
Una credenziale generata per un account amministratore Google Ads può essere utilizzata per accedere a tutti i relativi account secondari. Pertanto, per gli utenti con un'unica gerarchia di account amministratore, in genere è sufficiente generare una credenziale per l'account amministratore di livello superiore da utilizzare per tutti gli account Google Ads sottostanti.
Se la tua app deve accedere ad account Google Ads non correlati tra loro nella gerarchia dell'account amministratore, devi generare e gestire credenziali diverse per account diversi, ad esempio per ogni account cliente Google Ads a cui accedi o per ogni account amministratore di primo livello nelle gerarchie indipendenti a cui accedi.
Puoi seguire le stesse strategie per le app multithread o
multi-processo / distribuite con piccole modifiche. Quando utilizzi un datastore condiviso, le credenziali devono essere indicizzate dall'identificatore dell'account customerId per garantire che le credenziali siano associate all'account corretto.
Inoltre, il job di aggiornamento deve mantenere aggiornate tutte le credenziali. Se un nuovo account è collegato, potrebbe essere necessario attivare il job di aggiornamento.
Infine, nelle app multithread, dovresti condividere l'oggetto credenziali solo tra i thread che operano nell'account a cui è associato l'oggetto credenziali.