La condivisione delle credenziali tra le richieste API migliora le prestazioni ed evita un overhead eccessivo che può causare errori di limite 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 tua strategia di condivisione delle credenziali dipenderà dal fatto che la tua app sia multithreaded o multiprocesso (o distribuita). Un'app che è sia multiprocesso sia multithread all'interno di ogni processo deve utilizzare entrambe le strategie. Queste strategie possono essere adattate anche a più account Google Ads.
Multithreaded
Ogni sessione o utente estratto da un thread deve utilizzare lo stesso oggetto credenziale. Anche gli aggiornamenti del token di accesso devono essere eseguiti in modo sincrono per evitare condizioni di competizione.
Le nostre librerie client garantiscono che le credenziali siano un oggetto thread-safe che
si aggiorna in modo sincrono alla scadenza del token di accesso. Ogni libreria client
ha un oggetto sessione (o utente) con una credenziale che riutilizza
per tutta la sua durata. Per condividere le credenziali tra i thread, devi
costruire ogni sessione utilizzando le stesse credenziali. Ad esempio, nella libreria client Java, creeresti un singleton Credential e lo condivideresti tra tutte le sessioni.
Multiprocesso o distribuito
Per i processi multiprocesso o distribuiti, devi rendere persistenti le credenziali prima di poterle condividere. Per assicurarti che più processi o server non tentino di aggiornare le credenziali contemporaneamente, causando un numero eccessivo di richieste di aggiornamento, devi assegnare l'aggiornamento a un singolo processo.
Ad esempio, un job o un servizio separato può essere responsabile dell'aggiornamento periodico delle credenziali e del loro push proattivo in 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 delle credenziali attuali 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 restituiti.
Ti consigliamo di tenere traccia dell'ora in cui il token di accesso è stato aggiornato l'ultima volta e di forzare un aggiornamento se mancano meno di 5 minuti alla scadenza.
Se non sai quando è stato aggiornato l'ultima volta un token di accesso, puoi provare ad aggiornarlo supponendo che sia già scaduto. Se il token di accesso non è in scadenza, il server restituisce lo stesso token di accesso, insieme ai millisecondi rimanenti prima della scadenza del token.
Datastore
Puoi utilizzare un archivio dati 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, o datastore NoSQL, come MongoDB.
Il datastore deve essere ottimizzato per operazioni di lettura veloci, poiché ci saranno molte più richieste di lettura rispetto a quelle di scrittura. Inoltre, le credenziali devono essere memorizzate in modo sicuro.
Quando memorizzi la credenziale, devi memorizzare expiry_time
(ora + expires_in) e refresh_token insieme a access_token. Il
expiry_time viene calcolato come l'ora della richiesta di aggiornamento access_token
più il tempo expires_in.
Pool di server
Ogni server o processo nel pool recupera le credenziali più recenti dal datastore prima di effettuare una richiesta. Finché il job di aggiornamento viene eseguito correttamente, la credenziale sarà valida. Tuttavia, se il job di aggiornamento o l'archivio dati non va a buon fine, devi disporre di un meccanismo di fallback.
Se un server o un processo non riesce a ottenere una credenziale dall'archivio dati o se la credenziale è scaduta, il server deve aggiornare le proprie credenziali per consentire all'app di continuare a funzionare con l'API finché il problema non viene risolto.
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 una singola gerarchia di account amministratore, di solito è sufficiente generare una credenziale per l'account amministratore di primo livello da utilizzare per tutti gli account Google Ads sottostanti.
Se la tua app deve accedere ad account Google Ads non correlati tra loro in una gerarchia di 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 multithreaded o
multiprocesso / distribuite con piccole modifiche. Quando
utilizzi un archivio dati condiviso, le credenziali devono essere indicizzate in base all'identificatore dell'account
customerId per garantire che siano associate all'account corretto.
Inoltre, il job di aggiornamento deve mantenere aggiornate tutte le credenziali. Se viene collegato un nuovo account, potrebbe essere necessario attivare il job di aggiornamento.
Infine, nelle app multithread, devi condividere l'oggetto credenziale solo tra i thread che operano sull'account a cui è associato l'oggetto credenziale.