Upoważnienie
Wszystkie żądania wysyłane do interfejsu Google Photos Library API muszą być autoryzowane przez użytkownika.
Szczegóły procesu autoryzacji OAuth 2.0 różnią się nieco w zależności od rodzaju tworzonej aplikacji. Ten ogólny proces ma zastosowanie do wszystkich typów aplikacji:
- Przygotuj się do procesu autoryzacji:
- Zarejestruj aplikację, korzystając z Konsoli interfejsów API Google.
- Aktywuj interfejs Library API i pobierz szczegóły protokołu OAuth, takie jak identyfikator klienta i tajny klucz klienta. Więcej informacji znajdziesz w artykule Pierwsze kroki.
- Aby uzyskać dostęp do danych użytkownika, aplikacja wysyła do Google żądanie dotyczące konkretnego zakresu dostępu.
- Google wyświetla użytkownikowi ekran zgody z prośbą o autoryzowanie dostępu aplikacji do niektórych danych.
- Jeśli użytkownik wyrazi zgodę, Google dostarczy aplikacji token dostępu, który po krótkim czasie wygasa.
- Aplikacja wysyła żądanie udostępnienia danych użytkownika i łączy do żądania token dostępu.
- Jeśli Google uzna, że żądanie i token są prawidłowe, zwraca żądane dane.
Aby określić, które zakresy są odpowiednie dla Twojej aplikacji, przeczytaj artykuł o zakresach autoryzacji.
W przypadku niektórych typów aplikacji proces obejmuje dodatkowe kroki, takie jak wykorzystanie tokenów odświeżania do uzyskania nowych tokenów dostępu. Szczegółowe informacje o przepływach związanych z różnymi typami aplikacji znajdziesz w artykule o korzystaniu z protokołu OAuth 2.0 do uzyskiwania dostępu do interfejsów API Google.
Zapisywanie w pamięci podręcznej
Dbaj o aktualność danych
Jeśli ze względu na wydajność musisz tymczasowo przechowywać multimedia (np. miniatury, zdjęcia lub filmy), nie zapisuj ich w pamięci podręcznej na dłużej niż 60 minut zgodnie z naszymi wytycznymi dotyczącymi użytkowania.
Nie przechowuj też baseUrls, które wygasają po około 60 minutach.
Identyfikatory elementów multimedialnych i albumów, które jednoznacznie identyfikują treści w bibliotece użytkownika, nie są objęte ograniczeniem buforowania. Identyfikatory te możesz przechowywać bezterminowo (zgodnie z polityką prywatności aplikacji). Identyfikatory elementów multimedialnych i albumów pozwalają ponownie pobierać dostępne adresy URL oraz dane za pomocą odpowiednich punktów końcowych. Więcej informacji znajdziesz w artykułach o pobieraniu elementów multimedialnych i tworzeniu albumów z listą.
Jeśli masz do odświeżenia wiele elementów multimedialnych, lepiej zapisać parametry wyszukiwania, które je zwróciły, i ponownie przesłać zapytanie w celu ponownego załadowania danych.
Dostęp przez SSL
Protokół HTTPS jest wymagany w przypadku wszystkich żądań usługi internetowej Library API korzystających z tego adresu URL:
https://photoslibrary.googleapis.com/v1/service/output?parameters
Żądania przesłane przez HTTP są odrzucane.
Obsługa błędów
Informacje o obsłudze błędów zwracanych przez interfejs API znajdziesz w sekcji Obsługa błędów w Cloud API.
Ponawianie nieudanych żądań
Klienty powinni spróbować ponownie w przypadku błędów 5xx ze wzrastającym czasem ponowienia zgodnie z opisem w sekcji Wykładnicze opóźnienie ponowienia. Minimalne opóźnienie powinno wynosić 1 s, chyba że w dokumentacji określono inaczej.
W przypadku błędów 429 klient może ponowić próbę z minimalnym opóźnieniem 30s. W przypadku pozostałych błędów ponowienie może nie mieć zastosowania. Sprawdź, czy żądanie jest idempotentne, i zapoznaj się z komunikatem o błędzie.
Ponawianie wykładnicze
W rzadkich przypadkach podczas przetwarzania żądania coś może pójść nie tak.Możesz otrzymać kod odpowiedzi HTTP 4XX lub 5XX albo też błąd połączenia TCP między klientem a serwerem Google. Często warto spróbować ponownie. Dalsze działanie może się udać, jeśli pierwotna wersja się nie powiedzie. Pamiętaj jednak, by nie zapętlać serwerów, bo wtedy żądania do serwerów Google są wielokrotnie wysyłane. Takie zapętlenie może spowodować przeciążenie sieci między Twoim klientem a Google i spowodować problemy u wielu stron.
Lepszym rozwiązaniem jest ponowienie próby z rosnącymi opóźnieniami między próbami. Zazwyczaj opóźnienie jest zwiększane przez mnożnik przy każdej próbie, tzw. wykładniczy zwrot z inwestycji.
Dopilnuj też, aby w łańcuchu wywołań aplikacji nie znajdował się wyżej kod ponawiania, który prowadzi do powtarzających się żądań w szybkich odstępach czasu.
grzeczne korzystanie z interfejsów API Google,
Źle zaprojektowane klienty interfejsu API mogą powodować nadmierne obciążenie zarówno internetem, jak i serwerami Google. Ta sekcja zawiera kilka sprawdzonych metod dla klientów korzystających z interfejsów API. Stosując się do tych sprawdzonych metod, możesz uniknąć zablokowania aplikacji z powodu nieumyślnego nadużywania interfejsów API.
Zsynchronizowane żądania
Duża liczba zsynchronizowanych żądań wysyłanych do interfejsów API Google może przypominać atak typu DDoS na infrastrukturę Google i być odpowiednio traktowany. Aby tego uniknąć, sprawdź, czy żądania do interfejsu API nie są synchronizowane między klientami.
Weźmy na przykład aplikację, która wyświetla godzinę w bieżącej strefie czasowej. Ta aplikacja prawdopodobnie ustawi alarm w systemie operacyjnym klienta, wybudzając ją na początku minuty, aby można było zaktualizować wyświetlaną godzinę. Podczas przetwarzania powiązanego z tym alarmem aplikacja nie powinna wykonywać żadnych wywołań interfejsu API.
Wykonywanie wywołań interfejsu API w reakcji na stały alarm jest błędne, ponieważ powoduje to synchronizowanie wywołań interfejsu API na początku minuty, nawet między różnymi urządzeniami, a nie równomierne rozłożenie w czasie. Źle zaprojektowana aplikacja powoduje na początku każdej minuty gwałtowny wzrost natężenia ruchu przy 60-krotnie normalnym poziomie.
Zamiast tego można ustawić drugi alarm na losowo wybraną godzinę. Po uruchomieniu drugiego alarmu aplikacja wywołuje wszystkie potrzebne interfejsy API i zapisuje wyniki. Aby zaktualizować widok na początku minuty, aplikacja użyje zapisanych wcześniej wyników, zamiast ponownie wywoływać interfejs API. Przy tym podejściu wywołania interfejsu API są równomiernie rozkładane w czasie. Co więcej, wywołania interfejsu API nie opóźniają renderowania podczas aktualizacji wyświetlacza.
Poza początkiem minuty należy zadbać o to, by inne typowe godziny synchronizacji nie były ustawione na początek godziny i początek każdego dnia o północy.