Autoryzacja
Wszystkie żądania wysyłane do interfejsu Google Photos Library API muszą być autoryzowane przez uwierzytelnionego użytkownika.
Szczegóły procesu autoryzacji OAuth 2.0 różnią się nieco w zależności od w związku z rodzajem Państwa zgłoszenia. Jak wygląda ten ogólny proces dotyczy wszystkich typów aplikacji:
- Przygotuj się do procesu autoryzacji, wykonując te czynności:
- Zarejestruj aplikację za pomocą Konsola 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: Rozpocznij
- Aby uzyskać dostęp do danych użytkownika, aplikacja wysyła do Google żądanie do określonego zakresu.
- Google wyświetla użytkownikowi ekran zgody z prośbą o autoryzację o niektóre z nich.
- Jeśli użytkownik wyrazi zgodę, Google udostępnia aplikacji token dostępu. które wygasa po krótkim czasie.
- Aplikacja wysyła żądanie udostępnienia danych użytkownika i załącza token dostępu. do danej prośby.
- Jeśli Google ustali, że żądanie i token są prawidłowe, zwraca żądane dane.
Aby określić, które zakresy są odpowiednie dla Twojej aplikacji, zapoznaj się z sekcją Autoryzacja .
W przypadku niektórych typów aplikacji ten proces obejmuje dodatkowe kroki, takie jak użycie odśwież tokeny, aby uzyskać nowe tokeny dostępu. Szczegółowe informacje na temat: procedury dla różnych typów aplikacji znajdziesz w artykule Korzystanie z protokołu OAuth 2.0 do uzyskiwania dostępu do Google interfejsów API.
Pamięć podręczna
Dbaj o aktualność danych.
Jeśli chcesz tymczasowo przechowywać multimedia (np. miniatury, zdjęcia lub filmy) ze względu na wydajność, nie zapisuj pamięci podręcznej dłużej niż 60 minut po jej użyciu wytycznymi.
Nie przechowuj też plików baseUrls, które wygasają po około 60 sekundach
min.
identyfikatory elementów multimedialnych i albumów, które jednoznacznie identyfikują treść w bibliotece użytkownika; są zwolnione z ograniczenia buforowania. Te identyfikatory możesz przechowywać bez ograniczeń czasowych (zgodnie z polityką prywatności aplikacji). Używanie identyfikatorów elementów multimedialnych i albumów aby ponownie pobrać dostępne adresy URL i dane za pomocą odpowiednich punktów końcowych. Dla: więcej informacji znajdziesz w artykule Pobieranie multimediów item lub Listing (Informacje o produkcie) .
Jeśli masz wiele elementów multimedialnych do odświeżenia, lepiej przechowywać wyszukaj parametry, które zwróciły elementy multimedialne, i ponownie prześlij zapytanie w celu ponownego załadowania i skalowalnych danych.
Dostęp przez SSL
Protokół HTTPS jest wymagany w przypadku wszystkich żądań usług sieciowych Library API używających protokołu następujący adres URL:
https://photoslibrary.googleapis.com/v1/service/output?parameters
Żądania przesyłane przez HTTP są odrzucane.
Obsługa błędów
Informacje o tym, jak postępować w przypadku błędów zwróconych przez interfejs API, znajdziesz w sekcji dotyczącej Cloud Obsługa interfejsów API .
Ponawianie nieudanych żądań
Klienci powinni ponawiać próby po wystąpieniu 5xx błędów ze wzrastającym czasem do ponowienia, jak opisano w
Wykładniczy czas do ponowienia. Minimalne opóźnienie powinno wynosić 1 s
o ile nie podano inaczej.
W przypadku 429 błędów klient może ponowić próbę z minimalnym opóźnieniem 30s. Pozostałe urządzenia
błędy, ponowienie próby może nie mieć zastosowania. Upewnij się, że żądanie jest idempotentne i zobacz
zobaczysz komunikat o błędzie.
Wykładniczy czas do ponowienia
W rzadkich przypadkach może coś pójść nie tak przy realizacji żądania.Możesz otrzymać
Kod odpowiedzi HTTP 4XX lub 5XX albo połączenie TCP może gdzieś nie zadziałać
między Twoim klientem a serwerem Google. Często warto ponawiać próby
użytkownika. Dalsze żądanie może się udać, jeśli pierwotne żądanie nie zostało przetworzone. Pamiętaj jednak:
Ważne jest, by nie zapętlać się, wielokrotnie wysyłać żądania do serwerów Google. Ten
zapętlanie może spowodować przeciążenie sieci między klientem a Google
jest źródłem problemów wielu stron.
Lepszym sposobem jest ponowienie próby z coraz większymi opóźnieniami. Zwykle opóźnienie jest zwiększane przez mnożnik przy każdej próbie. znana jako wykładnicza czas ponowienia.
Zadbaj też o to, by w aplikacji nie znaleziono kodu, który ponowił próbę łańcuch wywołań, który prowadzi do powtarzających się żądań w krótkich odstępach czasu.
Kontrolowane korzystanie z interfejsów API Google
Źle zaprojektowane klienty interfejsu API mogą nakładać większe obciążenie niż to konieczne i na serwerach Google. W tej sekcji znajdziesz sprawdzone metody klientów interfejsów API. Stosując się do tych sprawdzonych metod, możesz uniknąć gdy aplikacja jest blokowana z powodu niezamierzonego nadużywania interfejsów API.
Zsynchronizowane żądania
Duża liczba zsynchronizowanych żądań do interfejsów API Google może wyglądać jak atak typu DDoS (Distributed Denial of Service) na infrastrukturę Google oraz są odpowiednie. Aby tego uniknąć, upewnij się, że żądania do interfejsu API są nie są synchronizowane między klientami.
Weźmy na przykład aplikację, która wyświetla godzinę w bieżącej godzinie strefie. Ta aplikacja prawdopodobnie ustawi alarm w systemie operacyjnym klienta budzi się na początku minuty, aby była wyświetlana godzina Zaktualizowano. W trakcie przetwarzania aplikacja nie powinna wykonywać żadnych wywołań interfejsu API powiązane z tym alarmem.
Wykonywanie wywołań interfejsu API w odpowiedzi na ustalony alarm jest szkodą, ponieważ skutkuje Wywołania interfejsu API synchronizowane na początku minuty, nawet między różnymi urządzeń, zamiast równomiernie rozkładać się w czasie. Źle zaprojektowana generuje skok liczby wizyt na poziomie 60 razy wyższym niż normalnie. na początku każdej minuty.
Jednym z dobrych rozwiązań jest ustawienie drugiego alarmu losowo, w wybranym czasie. Po uruchomieniu tego drugiego alarmu aplikacja wywołuje interfejsów API, których potrzebuje, i przechowuje wyniki. Aby zaktualizować wyświetlanie na początku polecenia na minutę, aplikacja używa zapisanych wcześniej wyników, zamiast wywoływać API. Dzięki temu wywołania interfejsu API są rozłożone równomiernie w czasie. Dalej: wywołania interfejsu API nie opóźniają renderowania podczas aktualizowania wyświetlacza.
Oprócz początku minuty inne typowe czasy synchronizacji należy pamiętać, że reklamy nie mogą znajdować się na początku godziny i początku codziennie o północy.