Autoryzacja
Wszystkie żądania wysyłane do interfejsów API Zdjęć Google muszą być autoryzowane przez 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. Do wszystkich typów aplikacji ma zastosowanie ten ogólny proces:
- Przygotuj się do procesu autoryzacji, wykonując te czynności:
- Zarejestruj aplikację za pomocą Konsola interfejsów API Google.
- Aktywuj interfejsy API Zdjęć i pobierz szczegóły 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 o określony zakres dostępu.
- Google wyświetla użytkownikowi ekran zgody z prośbą o autoryzację o niektóre z nich.
- Jeśli użytkownik wyrazi zgodę, Google przekazuje aplikacji token dostępu, który 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 proces obejmuje dodatkowe kroki, takie jak wykorzystanie tokenów odświeżania do uzyskania nowych tokenów 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 ze względu na wydajność musisz tymczasowo przechowywać treści multimedialne (np. miniatury, zdjęcia lub filmy), nie przechowuj ich w pamięci podręcznej dłużej niż 60 minut zgodnie z naszymi wskazówkami dotyczącymi korzystania.
Nie przechowuj też plików baseUrls, które wygasają po około 60 sekundach
min.
Identyfikatory multimediów i albumów, które jednoznacznie identyfikują treści w bibliotece użytkownika, są zwolnione z ograniczeń dotyczących 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. Więcej informacji znajdziesz w artykule Pobieranie multimediów lub Wyświetlanie albumów.
Jeśli masz wiele elementów multimedialnych do odświeżenia, może być wydajniejsze przechowywanie parametrów wyszukiwania, które zwróciły te elementy, i ponownie przesyłanie zapytania w celu ponownego załadowania danych.
Dostęp przez SSL
Protokół HTTPS jest wymagany w przypadku wszystkich żądań usług internetowych interfejsów API Zdjęć, które korzystają z protokołu ten 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ń
W przypadku błędów 5xx klienci powinni podejmować kolejne próby z wzrastającym czasem do ponownej próby zgodnie z opisem w sekcji Wzrastający czas do ponownej próby. Minimalny czas opóźnienia powinien wynosić 1 s, chyba że określono 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.
Wzrastający czas do ponownej próby
W rzadkich przypadkach może wystąpić błąd podczas obsługi Twojego żądania. Możesz otrzymać kod odpowiedzi HTTP 4XX lub 5XX albo połączenie TCP może się nie udać gdzieś między klientem a serwerem Google. Często warto ponownie wysłać żądanie. Ponowne żądanie może się powieść, gdy pierwotne nie powiodło się. Pamiętaj jednak:
Ważne jest, by nie zapętlać się, wielokrotnie wysyłać żądania do serwerów Google. Takie zachowanie może spowodować przeciążenie sieci między klientem a Google i spowodować problemy dla wielu stron.
Lepszym podejściem jest ponowne próbowanie z rosnącymi opóźnieniami między próbami. Zazwyczaj opóźnienie jest zwiększane o współczynnik mnożenia przy każdej próbie. Takie podejście nazywa się wykładniczym zmniejszaniem.
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. Stosowanie tych sprawdzonych metod może pomóc Ci uniknąć zablokowania aplikacji z powodu niezamierzonego nadużycia interfejsów API.
Zsynchronizowane żądania
Duża liczba synchronizowanych żądań do interfejsów API Google może wyglądać jak rozproszony atak typu DoS na infrastrukturę Google i być odpowiednio traktowana. Aby tego uniknąć, musisz zadbać o to, aby żądania interfejsu API nie były synchronizowane między klientami.
Weźmy na przykład aplikację, która wyświetla godzinę w bieżącej godzinie strefie. Aplikacja prawdopodobnie ustawi alarm w systemie operacyjnym klienta, który będzie ją wybudzać na początku minuty, aby zaktualizować wyświetlany czas. 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 naprawiony 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 aplikacja powoduje na początku każdej minuty 60-krotny wzrost natężenia ruchu.
Zamiast tego można ustawić drugi alarm na losową godzinę. Po uruchomieniu tego drugiego alarmu aplikacja wywołuje interfejsów API, których potrzebuje, i przechowuje wyniki. Aby zaktualizować wyświetlanie na początku minuty, aplikacja używa wcześniej zapisanych wyników zamiast ponownie wywoływać interfejs API. Dzięki temu wywołania interfejsu API są rozłożone równomiernie w czasie. Co więcej, 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.