Autorizzazione
Tutte le richieste all'API della Raccolta di Google Foto devono essere autorizzate da un utente autenticato.
I dettagli della procedura di autorizzazione per OAuth 2.0 variano leggermente a seconda sul tipo di applicazione che stai scrivendo. La seguente procedura generale si applica a tutti i tipi di applicazioni:
- Per prepararti al processo di autorizzazione:
- Registra la tua applicazione utilizzando Console API di Google.
- Attiva l'API Library 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 per il consenso in cui viene chiesto di autorizzare di richiedere alcuni dei propri 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 stabilisce che la richiesta e il token sono validi, restituisce il token i dati richiesti.
Per determinare quali ambiti sono adatti alla tua applicazione, consulta Autorizzazione ambiti.
La procedura per alcuni tipi di applicazione prevede passaggi aggiuntivi, come l'utilizzo 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 archiviare temporaneamente contenuti multimediali (ad esempio miniature, foto o video) per motivi legati alle prestazioni, non memorizzare nella cache per più di 60 minuti in base al nostro linee guida.
Non devi nemmeno archiviare 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 per un tempo indeterminato (soggette 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 di servizio web dell'API Library che utilizzano la classe 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 Cloud Gestione delle API errori.
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.
Per 429 errori, 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
richiesta. La richiesta di follow-up può avere esito positivo se l'originale non è andato a buon fine. Tuttavia,
è importante che non si verifichino loop, poiché ogni richiesta viene effettuata ripetutamente ai server di Google. Questo
un comportamento di loop può sovraccaricare la rete tra il client e Google
problemi a molte parti.
Un approccio migliore è riprovare con un ritardo maggiore tra un tentativo e l'altro. Di solito, il ritardo viene aumentato di un fattore moltiplicativo a ogni tentativo, un approccio noto come Esponenziale il backoff.
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 client delle API. Seguendo queste best practice puoi evitare dell'applicazione in caso di abuso involontario delle API.
Richieste sincronizzate
Un numero elevato di richieste sincronizzate alle API di Google può apparire come un attacco Distributed Denial of Service (DDoS) all'infrastruttura di Google e trattati di conseguenza. Per evitare che questo accada, assicurati che le richieste API vengano non sincronizzati tra i client.
Ad esempio, considera un'applicazione che mostra l'ora nell'ora corrente zona di destinazione. È 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 in modo uniforme 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.