Dostęp do Google Health API jest możliwy przez Google Cloud. Aby włączyć interfejs API i autoryzować konto Google, musisz mieć projekt Google Cloud.
Niezależnie od tego, czy jesteś deweloperem korzystającym z Fitbit API, czy dopiero zaczynasz korzystać z Google Health API, musisz wykonać ten krok, aby wywoływać interfejs API.
Tworzenie projektu i klienta OAuth
Aby włączyć Google Health API i uzyskać identyfikator klienta OAuth 2.0, kliknij przycisk Włącz API i uzyskaj identyfikator klienta OAuth 2.0:
- Jeśli masz już projekt Google Cloud, którego chcesz używać w Google Health API, najpierw zaloguj się na konto administratora tego projektu. Następnie po kliknięciu przycisku wybierz istniejący projekt z listy dostępnych projektów. W przeciwnym razie utwórz nowy projekt.
- Gdy pojawi się pytanie „Skąd wywołujesz?”, wybierz Serwer WWW.
- Jako wartość Autoryzowane identyfikatory URI przekierowania wpisz https://www.google.com. Identyfikator URI przekierowania jest wymagany do uzyskania kodu autoryzacji za pomocą OAuth 2.0.
- Po zakończeniu konfiguracji skopiuj wartości identyfikatora klienta OAuth 2.0 i tajnego klucza klienta oraz pobierz plik JSON z danymi logowania na komputer lokalny.
Jeśli chcesz ręcznie skonfigurować projekt Google Cloud lub sprawdzić konfigurację i ponownie pobrać dane logowania:
- Na stronie włączania interfejsu API włącz Google Health API.
- Na stronie Dane logowania uzyskaj identyfikator klienta OAuth 2.0.
Więcej informacji o konfigurowaniu OAuth 2.0 za pomocą konsoli Google znajdziesz w artykule Używanie protokołu OAuth 2.0 na potrzeby dostępu do interfejsów API Google.
Dodawanie użytkowników testowych
Domyślnie nowo utworzeni klienci OAuth są w stanie niezweryfikowanym i mają limit 100 użytkowników zarówno na potrzeby testowania, jak i w środowisku produkcyjnym. Aby w tym okresie włączyć autoryzację, musisz ręcznie dodać adres e-mail każdego użytkownika do listy użytkowników testowych w konfiguracji projektu.
Zaktualizuj listę użytkowników testowych na stronie Odbiorcy:
- Na tej stronie powinien być widoczny "Stan publikacji" ustawiony na Testowanie oraz "Typ użytkownika" ustawiony na Zewnętrzny.
- W sekcji "Użytkownicy testowi" kliknij + Dodaj użytkowników. Wpisz adres e-mail użytkowników testowych, którzy powinni mieć możliwość przyznania Twojej aplikacji uprawnień dostępu do swoich danych dotyczących zdrowia.
- Kliknij Zapisz.
Aby obsługiwać więcej niż 100 użytkowników za pomocą Google Health API, musisz przejść weryfikację bezpieczeństwa przeprowadzaną przez firmę zewnętrzną. Dodatkowe informacje znajdziesz w Centrum pomocy dotyczącym weryfikacji aplikacji OAuth.
Dodawanie zakresów
Na stronie Dostęp do danych musisz określić zakresy, które może wywoływać Twój klient:
- Na tej stronie kliknij Dodaj lub usuń zakresy.
- W kolumnie Interfejs API wyszukaj „Google Health API”. Wybierz zakresy, których potrzebujesz w aplikacji.
- Po wybraniu wszystkich potrzebnych zakresów kliknij Aktualizuj, aby wrócić na stronę Dostęp do danych.
- Kliknij Zapisz.
Konfiguracja identyfikatora klienta została zakończona. Możesz teraz wywoływać Google Health API.
Zaktualizuj zakresy
Możesz poprosić użytkownika o ponowne autoryzowanie aplikacji, ustawiając parametr prompt na consent w żądaniu uwierzytelnienia. Gdy uwzględnisz prompt=consent, ekran zgody będzie wyświetlany za każdym razem, gdy aplikacja poprosi o autoryzację zakresów dostępu, nawet jeśli wszystkie zakresy zostały wcześniej przyznane Twojemu projektowi Google API.
Aby dodać lub zmienić zakresy za pomocą parametru prompt=consent:
Określ pełną listę zakresów, których potrzebuje Twoja aplikacja. Powinny się na niej znaleźć zarówno dotychczasowe zakresy, jak i nowe, które chcesz dodać.
Zmodyfikuj parametr scope w adresie URL autoryzacji, aby uwzględnić zaktualizowaną listę wartości zakresów oddzielonych spacjami.
Dołącz
prompt=consentdo parametrów identyfikatora URI uwierzytelnienia. Spowoduje to, że serwer autoryzacji poprosi użytkownika o zgodę, zanim zwróci informacje do Twojego klienta.Poniższy przykład pokazuje żądanie HTTPS GET do punktu końcowego autoryzacji OAuth 2.0 Google z dołączonym
prompt=consent:https://accounts.google.com/o/oauth2/v2/auth?client_id=client-id&redirect_uri=redirect-uri&response_type=code&access_type=offline&scope=https://www.googleapis.com/auth/googlehealth.activity_and_fitness.readonly%20https://www.googleapis.com/auth/googlehealth.sleep.readonly&prompt=consent
Gdy użytkownik kliknie zaktualizowany link, zobaczy stronę zgody z listą wszystkich żądanych zakresów. Gdy użytkownik kliknie „Dalej” lub „Zezwól”, otrzymasz nowy kod autoryzacji, który można wymienić na tokeny obejmujące pełny zestaw zakresów.
Używaj
prompt=consenttylko wtedy, gdy jest to konieczne, np. gdy musisz uzyskać nowy token odświeżania lub gdy zmieniły się żądane zakresy.
Biblioteki klienta OAuth2
Listę dostępnych bibliotek klienta OAuth2 używanych do integracji z popularnymi platformami znajdziesz w artykule Używanie protokołu OAuth 2.0 na potrzeby dostępu do interfejsów API Google.
Tokeny odświeżania
Aby utrzymać długoterminowy dostęp do interfejsów API Google bez konieczności ciągłego ponownego uwierzytelniania użytkownika, aplikacja musi używać tokena odświeżania. Szczegółowe informacje o implementacji, w tym konkretne żądania HTTP i wymagane parametry, znajdziesz w dokumentacji platformy Google Identity.
Aby wymienić token odświeżania na token dostępu, wyślij żądanie HTTPS POST do punktu końcowego tokena Google OAuth 2.0. Poniższy fragment kodu przedstawia przykładowe żądanie i odpowiedź:
Żądanie
curl -L -X POST 'https://oauth2.googleapis.com/token' \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d 'client_id=client-id&client_secret=client-secret&refresh_token=refresh-token&grant_type=refresh_token'
Odpowiedź
{
"access_token": "access-token",
"expires_in": 3599,
"scope": "scope-list",
"token_type": "Bearer",
"refresh_token": "refresh-token",
"refresh_token_expires_in": 112154
}Działanie tokena podczas testowania
Pamiętaj, jak działają tokeny odświeżania w zależności od stanu publikacji projektu Google Cloud:
- Tryb testowania: jeśli ekran zgody OAuth jest skonfigurowany ze stanem publikacji „Testowanie”, wydane tokeny odświeżania są oparte na czasie i wygasają po 7 dniach. W tym okresie otrzymasz jeden token odświeżania, który pozostanie ważny i będzie można go używać do uzyskiwania nowych tokenów dostępu do daty wygaśnięcia.
- Tryb opublikowany: gdy aplikacja zostanie przeniesiona do stanu „W środowisku produkcyjnym”, tokeny odświeżania zwykle nie wygasają, chyba że zostaną unieważnione lub pozostaną nieużywane przez dłuższy czas (zwykle 6 miesięcy).
Aby zapewnić użytkownikom wygodę, opublikuj aplikację, zanim zostanie ona przeniesiona do środowiska produkcyjnego, aby uniknąć wygaśnięcia tokena po 7 dniach.