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 applicazioni:
- Preparati alla procedura di autorizzazione nel seguente modo:
- Registra la tua applicazione utilizzando Console API di Google.
- Attiva le API Foto e recupera i dettagli OAuth, ad esempio un e un client secret. Per ulteriori informazioni, vedi Inizia.
- Per accedere ai dati utente, l'applicazione invia a Google una richiesta di un particolare 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 scadono 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'utilizzo di token di aggiornamento per acquisire nuovi token di accesso. Per informazioni dettagliate su per vari tipi di applicazioni. Consulta l'articolo sull'utilizzo di OAuth 2.0 per accedere a per le API.
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.
ID degli elementi multimediali e degli album che identificano in modo univoco i contenuti nella raccolta di un utente. sono esenti dalle restrizioni di memorizzazione nella cache. Puoi archiviare questi ID a tempo indeterminato (in base alle norme sulla privacy della tua applicazione). Utilizzare gli ID elemento multimediale e gli ID album il recupero di URL e dati accessibili utilizzando gli endpoint appropriati. Per Per ulteriori informazioni, consulta la sezione Ottenere un voce o Scheda album.
Se hai molti elementi multimediali da aggiornare, potrebbe essere più efficiente archiviare il i parametri di ricerca che hanno restituito gli elementi multimediali e hanno inviato nuovamente la query per ricaricare e i dati di Google Cloud.
Accesso SSL
HTTPS è richiesto per tutte le richieste al servizio web delle API 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.
Nuovo tentativo di richieste non riuscite
I client devono riprovare in caso di errori 5xx con 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, un nuovo tentativo potrebbe non essere applicabile. Assicurati che la tua richiesta sia idempotente e controlla
il messaggio di errore per indicazioni.
Backoff esponenziale
In rari casi, potrebbe verificarsi un problema nella gestione della tua richiesta.Potresti ricevere un
Codice di risposta HTTP 4XX o 5XX oppure la connessione TCP potrebbe non riuscire da qualche parte
tra il tuo 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 creare loop, perché ogni volta che vengono inviate richieste ai server di Google è importante. 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.
Devi inoltre fare attenzione che non esista un codice per nuovi tentativi più in alto nell'applicazione che porta a richieste ripetute in rapida successione.
Utilizzo "gentile" delle API di Google
I client API progettati in modo inadeguato possono applicare un carico maggiore del necessario sia al internet e 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 che questo accada, assicurati che le richieste API vengano non sincronizzati tra i client.
Ad esempio, prendi in considerazione un'applicazione che mostra l'ora nel fuso orario corrente. È probabile che questa applicazione imposti un allarme nel sistema operativo client attivandolo all'inizio del minuto in modo che l'ora visualizzata possa aggiornato. L'applicazione non deve effettuare chiamate API nell'ambito dell'elaborazione associati a quella sveglia.
Effettuare chiamate API in risposta a un allarme fisso è un'azione negativa perché Chiamate API sincronizzate all'inizio del minuto, anche tra diverse i dispositivi, invece di essere distribuiti in modo uniforme nel tempo. Un design mal progettato questa operazione produce un picco di traffico a livelli 60 volte normali all'inizio di ogni minuto.
Una buona idea è quella di avere una seconda sveglia impostata su una durata casuale all'orario prescelto. Quando si attiva questo secondo allarme, l'applicazione effettua chiamate a qualsiasi le API necessarie e archiviano i risultati. Per aggiornarne la visualizzazione all'inizio del al minuto, l'applicazione utilizza risultati archiviati in precedenza anziché chiamare il metodo API di Google Cloud. Con questo approccio, le chiamate API vengono distribuite uniformemente nel tempo. Inoltre, le chiamate API non ritardano il rendering quando il display viene aggiornato.
Oltre all'inizio del minuto, altri orari di sincronizzazione comunemente devi fare attenzione a non essere all'inizio di un'ora e all'inizio tutti i giorni a mezzanotte.