Autorizzazione
Tutte le richieste alle API di Google Foto devono essere autorizzate da un utente autenticato.
I dettagli della procedura di autorizzazione per OAuth 2.0 variano leggermente a seconda del tipo di applicazione che stai scrivendo. La seguente procedura generale si applica a tutti i tipi di applicazione:
- Preparati alla procedura di autorizzazione nel seguente modo:
- Registra la tua applicazione utilizzando la console API di Google.
- Attiva le API di Foto e recupera i dettagli di OAuth, ad esempio un ID client e un client secret. Per ulteriori informazioni, consulta la guida introduttiva.
- Per accedere ai dati utente, l'applicazione invia a Google una richiesta per un determinato ambito di accesso.
- Google mostra all'utente una schermata di consenso in cui gli viene chiesto di autorizzare l'applicazione a richiedere alcuni dei suoi dati.
- Se l'utente approva, Google fornisce all'applicazione un token di accesso che scade dopo un breve periodo di tempo.
- L'applicazione invia una richiesta per i dati utente, allegando il token di accesso alla richiesta.
- Se Google ritiene validi la richiesta e il token, restituisce i dati richiesti.
Per determinare quali ambiti sono adatti alla tua applicazione, consulta Ambiti dell'autorizzazione.
La procedura per alcuni tipi di applicazioni include passaggi aggiuntivi, come l'uso di token di aggiornamento per acquisire nuovi token di accesso. Per informazioni dettagliate sui flussi per vari tipi di applicazioni, consulta l'articolo sull'utilizzo di OAuth 2.0 per accedere alle API di Google.
Memorizzazione nella cache
Mantieni i dati aggiornati.
Se devi memorizzare temporaneamente contenuti multimediali (ad esempio miniature, foto o video) per motivi di prestazioni, non memorizzarli nella cache per più di 60 minuti in base alle nostre linee guida sull'utilizzo.
Inoltre, non devi conservare baseUrls, che scadono dopo circa 60
minuti.
Gli ID elemento multimediale e gli ID album che identificano in modo univoco i contenuti nella raccolta di un utente sono esenti dalla limitazione della memorizzazione nella cache. Puoi archiviare questi ID a tempo indeterminato (in base alle norme sulla privacy della tua applicazione). Utilizza gli ID elementi multimediali e gli ID album per recuperare di nuovo gli URL e i dati accessibili utilizzando gli endpoint appropriati. Per maggiori informazioni, vedi Ottenere un elemento media o Eseguire l'inventario degli album.
Se hai molti elementi multimediali da aggiornare, potrebbe essere più efficiente memorizzare i parametri di ricerca che hanno restituito gli elementi multimediali e inviare nuovamente la query per ricaricare i dati.
Accesso SSL
HTTPS è obbligatorio per tutte le richieste di servizi web delle API di Foto che utilizzano il seguente URL:
https://photoslibrary.googleapis.com/v1/service/output?parameters
Le richieste effettuate tramite HTTP vengono rifiutate.
Gestione degli errori
Per informazioni su come gestire gli errori restituiti dall'API, consulta Gestione degli errori nelle API Cloud.
Riprovare le richieste non riuscite
I client devono riprovare in caso di errori 5xx con il backoff esponenziale come descritto in
Backoff esponenziale. Il ritardo minimo deve essere 1 s
se non diversamente documentato.
In caso di errori 429, il client può riprovare con un ritardo minimo di 30s. Per tutti gli altri
errori, la ripetizione potrebbe non essere applicabile. Assicurati che la richiesta sia idempotente e consulta il messaggio di errore per indicazioni.
Backoff esponenziale
In rari casi, la pubblicazione della richiesta potrebbe non andare a buon fine.Potresti ricevere un codice di risposta HTTP 4XX o 5XX oppure la connessione TCP potrebbe non riuscire da qualche parte tra il client e il server di Google. Spesso vale la pena riprovare a inviare la richiesta. La richiesta di follow-up potrebbe andare a buon fine quando quella originale non è andata a buon fine. Tuttavia,
è importante non eseguire un ciclo, inviando ripetutamente richieste ai server di Google. Questo comportamento di looping può sovraccaricare la rete tra il client e Google e causare problemi a molte parti.
Un approccio migliore è quello di riprovare con ritardi crescenti tra un tentativo e l'altro. Di solito, il ritardo viene aumentato di un fattore moltiplicativo a ogni tentativo, un approccio noto come backoff esponenziale.
Inoltre, assicurati che nella catena di chiamate dell'applicazione non sia presente un codice di ripetizione che porti a richieste ripetute in rapida successione.
Utilizzo corretto delle API di Google
Client API progettati male possono generare un carico maggiore del necessario sia su internet sia sui server di Google. Questa sezione contiene alcune best practice per i clienti delle API. Seguire queste best practice può aiutarti a evitare il blocco della tua applicazione per uso improprio involontario delle API.
Richieste sincronizzate
Un numero elevato di richieste sincronizzate alle API di Google può sembrare un attacco Distributed Denial of Service (DDoS) all'infrastruttura di Google e essere trattato di conseguenza. Per evitare ciò, devi assicurarti che le richieste API non siano sincronizzate tra i client.
Ad esempio, prendi in considerazione un'applicazione che mostra l'ora nel fuso orario corrente. Questa applicazione probabilmente imposterà una sveglia nel sistema operativo del client per risvegliarlo all'inizio del minuto in modo che l'ora visualizzata possa essere aggiornata. L'applicazione non deve effettuare chiamate API nell'ambito dell'elaborazione associata all'allarme.
Eseguire chiamate API in risposta a una sveglia fissa non è consigliabile perché le chiamate API vengono sincronizzate con l'inizio del minuto, anche tra dispositivi diversi, anziché essere distribuite in modo uniforme nel tempo. Un'applicazione progettata male che esegue questa operazione produce un picco di traffico pari a sessantacinque volte i livelli normali all'inizio di ogni minuto.
Invece, un possibile buon design è impostare una seconda sveglia su un orario scelto in modo random. Quando viene attivato questo secondo avviso, l'applicazione effettua chiamate a tutte le API di cui ha bisogno e memorizza i risultati. Per aggiornare la visualizzazione all'inizio del minuto, l'applicazione utilizza i risultati memorizzati in precedenza anziché richiamare nuovamente l'API. Con questo approccio, le chiamate API vengono distribuite uniformemente nel tempo. Inoltre, le chiamate API non ritardano il rendering durante l'aggiornamento del display.
Oltre all'inizio del minuto, altri orari di sincronizzazione comuni che devi fare attenzione a non scegliere come target sono l'inizio di un'ora e l'inizio di ogni giorno a mezzanotte.