Przegląd

Interfejs Google Health API to nowy interfejs API stworzony od podstaw, który umożliwia deweloperom wysyłanie zapytań o dane użytkowników Fitbita. To nie tylko aktualizacja, ale strategiczne działanie, które ma zapewnić bezpieczeństwo i niezawodność Twoich aplikacji oraz przygotować je na przyszłe postępy w technologii medycznej. Interfejs API obsługuje nową konsolę do rejestrowania aplikacji, protokół Google OAuth 2.0, nowe typy danych, nowy schemat punktu końcowego i nowy format odpowiedzi.

Ten przewodnik ma pomóc deweloperom w migracji dotychczasowych aplikacji korzystających z interfejsu Fitbit Web API do nowego interfejsu Google Health API.

Dlaczego warto przeprowadzić migrację?

Korzyści z korzystania z interfejsu API Google Health:

• Zwiększone bezpieczeństwo: zgodność ze sprawdzonymi metodami Google w zakresie bezpieczeństwa, zgodność ze standardami Google dotyczącymi bezpieczeństwa, prywatności i tożsamości.
• Spójność: eliminuje starsze niespójności w formatach danych, strefach czasowych, jednostkach miary i obsłudze błędów, aby zapewnić bardziej intuicyjną obsługę dla programistów.
• Skalowalność i zabezpieczenie na przyszłość: zaprojektowany z myślą o skalowalności, aby sprostać przyszłym wymaganiom, i obsługuje nowoczesne protokoły, takie jak gRPC.

Przenoszenie użytkowników

Przejście z interfejsu Fitbit Web API na interfejs Google Health API to coś więcej niż tylko aktualizacja techniczna. Ze względu na zmianę biblioteki OAuth użytkownicy muszą ponownie wyrazić zgodę na nową integrację. Nie można przenieść tokenów dostępu i tokenów odświeżania do interfejsu Google Health API i ich używać. Aby pomóc Ci utrzymać użytkowników podczas migracji, przygotowaliśmy kilka technicznych i strategicznych sugestii, które pomogą Ci przeprowadzić ją z sukcesem.

Strategia dwóch bibliotek

Interfejs Fitbit Web API i interfejs Google Health API korzystają z różnych bibliotek OAuth2, więc musisz zarządzać okresem „pomostowym”, w którym w kodzie źródłowym istnieją obie biblioteki.

Równoległe zarządzanie autoryzacją

• Enkapsulacja klientów: utwórz warstwę abstrakcji lub interfejs dla „usługi zdrowotnej”. Dzięki temu pozostała część aplikacji może żądać danych bez wiedzy o tym, która biblioteka (Fitbit OAuth czy Google OAuth) jest aktywna w przypadku danego użytkownika.
• Aktualizacja schematu bazy danych: zaktualizuj tabelę użytkowników, aby uwzględnić w niej flagę oauth_type. Na przykład użyj fitbit w przypadku OAuth Fitbita i google w przypadku OAuth Google.
  • Nowi użytkownicy: domyślnie używaj interfejsu Google Health API i biblioteki Google OAuth. Ustaw oauth_type na google.
  • Dotychczasowi użytkownicy: nadal korzystaj z interfejsu Fitbit Web API, dopóki nie przejdą ponownie procesu uzyskiwania zgody. Ustaw wartość oauth_type na fitbit.

Proces ponownego uzyskiwania zgody „Step-Up”

Zamiast wymuszać wylogowanie, użyj autoryzacji przyrostowej:

1. Wykrywanie tokena open source Fitbit: gdy użytkownik interfejsu Fitbit Web API otworzy aplikację, wyślij powiadomienie „Aktualizacja usługi”.
2. Uruchom obsługę protokołu Google OAuth: gdy użytkownik kliknie „Aktualizuj”, uruchom obsługę biblioteki Google OAuth2.
3. Zastąp i unieważnij: po otrzymaniu tokena Google OAuth zapisz go w profilu użytkownika, zaktualizuj oauth_type z fitbit na google i (w miarę możliwości) programowo unieważnij stary token fitbit, aby zachować bezpieczeństwo profilu użytkownika.

Maksymalizacja utrzymania użytkowników

Ponowne uzyskanie zgody to „strefa zagrożenia” rezygnacją. Aby zapobiec porzuceniu aplikacji przez użytkowników, postępuj zgodnie z tymi sprawdzonymi metodami dotyczącymi wrażeń użytkownika:

Komunikacja oparta na wartości

Nie zaczynaj od „Zaktualizowaliśmy nasz interfejs API”. Najpierw przedstaw korzyści nowego systemu wspieranego przez Google:

• Większe bezpieczeństwo: wspomnij o najlepszej w branży ochronie konta Google i weryfikacji dwuetapowej.
• Niezawodność: krótszy czas synchronizacji i stabilniejsze połączenia z danymi.
• Blokowanie funkcji: delikatne informowanie użytkowników, że nowe funkcje i typy danych wymagają aktualizacji.

Inteligentne wyznaczanie czasu

• Nie przerywaj ważnych zadań: nigdy nie wyświetlaj ekranu ponownej zgody, gdy użytkownik jest w trakcie treningu lub rejestruje posiłek.
• Faza „zachęty”: przez pierwsze 30 dni używaj banera, który można zamknąć.
• Faza „ostatecznego wyłączenia”: ponowne uzyskanie zgody będzie wymagane dopiero po kilku tygodniach wyświetlania ostrzeżeń, co zbiegnie się w czasie z oficjalnymi terminami wycofania interfejsu Fitbit Web API.

Porównanie procesu migracji

Wyraźne rozróżnienie wizualne między starym a nowym przepływem pomaga deweloperom zrozumieć, gdzie następuje rozwidlenie logiki.

Funkcja	Fitbit Web API (starsza wersja)	Google Health API (Google-Identity)
Biblioteka uwierzytelniania	Standardowe oprogramowanie open source	Google Identity Services (GIS) / Google Auth
Konta użytkowników	Starsze dane logowania Fitbita	Konto Google
Typ tokena	Dostęp do Fitbita i odświeżanie	Tokeny dostępu i tokeny odświeżania wydane przez Google
Zarządzanie zakresem	Szerokie uprawnienia	Szczegółowe / przyrostowe uprawnienia

Zrozumienie niuansów migracji konta

Zgodnie z dokumentacją Fitbita użytkownicy, którzy przenoszą swoje konto do Google, zwykle nie tracą od razu połączeń z usługami innych firm, ale zmiana wersji interfejsu API jest wymagana po stronie programisty.

• Sprawdź ważność tokena: użyj procesu w tle, aby sprawdzić, czy tokeny Fitbit zwracają błędy „Nieautoryzowany”. Może to oznaczać, że użytkownik przeniósł konto, ale Twoja aplikacja nie została zaktualizowana.
• Graceful Failures: jeśli wywołanie OAuth Fitbita się nie powiedzie, przekieruj użytkownika na niestandardową stronę „Połącz ponownie Fitbita”, która korzysta z nowego przepływu OAuth Google.