La condivisione delle credenziali tra le richieste API migliora le prestazioni ed evita un overhead eccessivo che può causare errori relativi ai limiti 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 multi-thread o multiprocesso (o distribuita). Un'app multiprocesso e multithread all'interno di ciascun processo dovrebbe applicare 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 gare di condizioni.
Le nostre librerie client garantiscono che la credenziale sia un oggetto thread-safe che si aggiorna in modo sincrono alla scadenza del token di accesso. Ognuna delle nostre librerie client ha un oggetto sessione (o utente) con una credenziale che riutilizza per tutta la durata. Per condividere la credenziale tra i thread, è sufficiente creare ogni sessione utilizzando la stessa credenziale. Ad esempio, nella libreria client Java, potresti 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 provino ad aggiornare la credenziale contemporaneamente, generando troppe 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 della credenziale e del relativo push 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 della credenziale attuale prima di avviare un aggiornamento. Questo potrebbe causare lo stallo dell'app per la mancanza di una credenziale valida; tuttavia, se il token di accesso di una credenziale scade mentre la richiesta API è in fase di elaborazione, la richiesta verrà comunque completata e i risultati restituiti.
Ti consigliamo di tenere traccia dell'ora dell'ultimo aggiornamento del token di accesso e di forzare l'aggiornamento se mancano meno di 5 minuti alla scadenza.
Se non sai quando un token di accesso è stato aggiornato l'ultima volta, puoi provare ad aggiornarlo supponendo che sia già scaduto. Se il token di accesso non è prossimo alla scadenza, il server restituisce lo stesso token di accesso, insieme ai millisecondi rimanenti fino alla scadenza del token.
Datastore
Puoi utilizzare un datastore esistente o eseguirne il deployment di un datastore 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, dato che ci saranno molte più richieste di lettura che scritture. Inoltre, le credenziali devono essere archiviate in modo sicuro.
Quando archivi la credenziale, devi archiviare i valori calcolati di expiry_time (ora + expires_in) e refresh_token insieme a access_token. Il valore
expiry_time viene calcolato come il tempo 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. Se il job di aggiornamento viene eseguito correttamente, la credenziale sarà valida. Tuttavia, se il job di aggiornamento o l'archivio dati non riesce, dovresti avere un meccanismo di fallback.
Se un server o un processo non riesce a ottenere una credenziale dal datastore o se le credenziali sono scadute, il server deve aggiornare le proprie credenziali per consentire all'app di continuare a utilizzare l'API fino a quando 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. Di conseguenza, per gli utenti con un'unica gerarchia di account amministratore, di solito è 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 in qualsiasi gerarchia di account amministratore, devi generare e mantenere credenziali diverse per account cliente 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 multi-thread o
multiprocesso / distribuite con piccole modifiche. Quando si utilizza un datastore condiviso, le credenziali devono essere indicizzate dall'identificatore dell'account customerId per garantire che siano associate all'account corretto.
Inoltre, il job di aggiornamento dovrebbe mantenere aggiornate tutte le credenziali. Se è collegato un nuovo account, potrebbe essere necessario attivare il job di aggiornamento.
Infine, nelle app multithread, devi condividere l'oggetto credenziali solo tra i thread operativi nell'account a cui è associato l'oggetto credenziali.