Autoryzacja
Wszystkie żądania wysyłane do interfejsów API Zdjęć Google muszą być autoryzowane przez użytkownika.
Szczegóły procesu autoryzacji z użyciem protokołu OAuth 2.0 różnią się nieznacznie w zależności od rodzaju projektowanej aplikacji. Do wszystkich typów aplikacji ma zastosowanie ten ogólny proces:
- Przygotuj się do procesu autoryzacji:
- Zarejestruj aplikację w Konsoli interfejsów API Google.
- Aktywuj interfejsy API Zdjęć i pobierz szczegóły 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 o określony zakres 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 przekazuje aplikacji token dostępu, który wygasa po krótkim czasie.
- Aplikacja wysyła żądanie o dane użytkownika, dołączając do niego token dostępu.
- Jeśli Google uzna, że żądanie i token są prawidłowe, przesyła dane, o które prosisz.
Aby dowiedzieć się, które zakresy są odpowiednie dla Twojej aplikacji, zapoznaj się z artykułem Zakresy 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 procesach obowiązujących w przypadku różnych typów aplikacji znajdziesz w artykule Używanie protokołu OAuth 2.0 do korzystania z interfejsów API Google.
Pamięć podręczna
Odświeżaj dane.
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ż baseUrls, które wygasają po około 60 minutach.
Identyfikatory multimediów i albumów, które jednoznacznie identyfikują treści w bibliotece użytkownika, są zwolnione z ograniczeń dotyczących buforowania. Możesz przechowywać te identyfikatory bezterminowo (zgodnie z polityką prywatności aplikacji). Użyj identyfikatorów multimediów i albumów, aby ponownie pobrać dostępne adresy URL i dane, używając 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żesz przechowywać parametry wyszukiwania, które zwróciły te elementy, i ponownie przesłać zapytanie, aby ponownie załadować dane.
Dostęp SSL
Protokół HTTPS jest wymagany w przypadku wszystkich żądań interfejsów API usługi internetowej Zdjęć Google używających tego adresu URL:
https://photoslibrary.googleapis.com/v1/service/output?parameters
Żądania wysyłane przez HTTP są odrzucane.
Obsługa błędów
Informacje o obsługiwaniu błędów zwracanych przez interfejs API znajdziesz w artykule Obsługa błędów w interfejsach API w chmurze.
Ponawianie nieudanych żądań
W przypadku błędów 5xx klienci powinni podejmować kolejne próby z użyciem wzrastającego czasu 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 błędów 429 klient może podjąć kolejną próbę z minimalnym opóźnieniem 30s. W przypadku innych błędów ponowne próby mogą nie być możliwe. Upewnij się, że żądanie jest idempotentne, i sprawdź komunikat o błędzie, aby uzyskać wskazówki.
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ę. Ważne jest jednak, aby nie tworzyć pętli, wielokrotnie wysyłając żą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.
Upewnij się też, że w łańcuchu wywołań aplikacji nie ma kodu próby ponownego wykonania, który prowadzi do powtarzających się żądań w szybkiej kolejności.
Uprzejme korzystanie z interfejsów API Google
Źle zaprojektowane aplikacje korzystające z interfejsu API mogą generować niepotrzebnie duże obciążenie zarówno w internecie, jak i na serwerach Google. Ta sekcja zawiera sprawdzone metody dotyczące 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.
Synchronizowane żądania
Duża liczba synchronizowanych żądań do interfejsów API Google może wyglądać jak rozproszony atak typu „odmowa usługi” 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 czas w bieżącej strefie czasowej. Aplikacja prawdopodobnie ustawi alarm w systemie operacyjnym klienta, który będzie ją wybudzać na początku minuty, aby zaktualizować wyświetlany czas. Aplikacja nie powinna wykonywać żadnych wywołań interfejsu API w ramach przetwarzania związanego z tym alarmem.
Wykonywanie wywołań interfejsu API w odpowiedzi na ustalony alarm jest niekorzystne, ponieważ powoduje, że wywołania interfejsu API są synchronizowane z początkiem minuty, nawet na różnych urządzeniach, zamiast być rozłożone równomiernie 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ę. Gdy ten drugi alarm się włączy, aplikacja wywołuje interfejsy 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.
Poza początkiem minuty innymi typowymi momentami synchronizacji, których nie należy uwzględniać w kierowaniu, są początek godziny i początek każdego dnia o północy.