Przegląd

Interfejs Google Health API to nowy interfejs API, który umożliwia deweloperom wysyłanie zapytań o dane użytkowników Fitbita. Nie jest to tylko aktualizacja, ale strategiczny krok, który ma zapewnić bezpieczeństwo i niezawodność Twoich aplikacji oraz przygotować je na przyszłe postępy w technologii zdrowotnej. Interfejs API obsługuje nową konsolę do rejestrowania aplikacji, Google OAuth 2.0, nowe typy danych, nowy schemat punktów końcowych i nowy format odpowiedzi.

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

Dlaczego warto przeprowadzić migrację?

Korzyści z korzystania z interfejsu Google Health API:

  • Większe bezpieczeństwo: zgodność ze sprawdzonymi metodami Google dotyczącymi bezpieczeństwa, zgodność z normami Google w zakresie bezpieczeństwa, prywatności i tożsamości.
  • Spójność: eliminuje niezgodności w starszych formatach danych, strefach czasowych, jednostkach miary i obsłudze błędów, co zapewnia bardziej intuicyjną obsługę dla deweloperów.
  • Skalowalność i odporność na przyszłe zmiany: interfejs został zaprojektowany tak, aby można go było skalować w celu zaspokojenia przyszłych potrzeb, i obsługuje nowoczesne protokoły, takie jak gRPC.

Migracja użytkowników

Migracja z interfejsu Fitbit Web API do interfejsu Google Health API to coś więcej niż tylko aktualizacja techniczna. Ze względu na zmianę biblioteki OAuth Twoi 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. Aby pomóc Ci w utrzymaniu użytkowników podczas migracji, przedstawiamy kilka sugestii technicznych i strategicznych dotyczących pomyślnej migracji.

Strategia podwójnej biblioteki

Ponieważ interfejs Fitbit Web API i interfejs Google Health API używają różnych bibliotek OAuth2, musisz zarządzać okresem „przejściowym”, w którym obie biblioteki będą znajdować się w Twojej bazie kodu.

Równoległe zarządzanie autoryzacją

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

Proces ponownego wyrażania zgody „Step-Up”

Zamiast wymuszać wylogowanie, użyj podejścia autoryzacji przyrostowej:

  1. Wykrywanie tokena open source Fitbit: gdy użytkownik interfejsu Fitbit Web API otworzy aplikację, wyślij powiadomienie „Aktualizacja usługi”.
  2. Uruchamianie procesu Google OAuth: gdy użytkownik kliknie „Aktualizuj”, uruchom proces biblioteki Google OAuth2.
  3. Zastępowanie i unieważnianie: gdy token Google OAuth zostanie odebrany, zapisz go w profilu użytkownika, zaktualizuj oauth_type z fitbit na google i (jeśli to możliwe) programowo unieważnij stary token fitbit, aby zachować czystość profilu bezpieczeństwa użytkownika.

Maksymalizacja utrzymania użytkowników

Ponowne wyrażenie zgody to „strefa zagrożenia” dla rezygnacji. Aby zapobiec porzucaniu aplikacji przez użytkowników, postępuj zgodnie z tymi sprawdzonymi metodami UX:

Komunikacja „Value-First”

Nie zaczynaj od „Zaktualizowaliśmy nasz interfejs API”. Zacznij od korzyści wynikających z nowego systemu obsługiwanego przez Google:

  • Większe bezpieczeństwo: wspomnij o najlepszej w branży ochronie konta Google i uwierzytelnianiu dwuskładnikowym.
  • Niezawodność: krótsze czasy synchronizacji i bardziej stabilne połączenia danych.
  • Ograniczanie dostępu do funkcji: poinformuj użytkowników, że nowe funkcje i typy danych wymagają aktualizacji.

Inteligentne planowanie

  • Nie przerywaj ważnych zadań: nigdy nie wyświetlaj ekranu ponownego wyrażenia zgody , gdy użytkownik jest w trakcie treningu lub rejestrowania posiłku.
  • Faza „zachęcania”: przez pierwsze 30 dni używaj banera, który można zamknąć.
  • Faza „ostatecznego odcięcia”: ponowne wyrażenie zgody będzie obowiązkowe dopiero po kilku tygodniach ostrzeżeń, co zbiegnie się z oficjalnymi terminami wycofania interfejsu Fitbit Web API.

Porównanie procesu migracji

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

Funkcja Fitbit Web API (starsza wersja) Google Health API (Google-Identity)
Biblioteka uwierzytelniania Standard Open Source Google Identity Services (GIS) / Uwierzytelnianie Google
Konta użytkowników Starsze dane logowania Fitbit Konto Google
Typ tokena Dostęp / odświeżanie specyficzne dla Fitbita Tokeny dostępu/odświeżania wydane przez Google
Zarządzanie zakresem Szerokie uprawnienia Szczegółowe / przyrostowe uprawnienia

Obsługa niuansów migracji konta

Zgodnie z dokumentacją Fitbita użytkownicy migrujący swoje konto do Google zwykle nie tracą od razu połączeń z innymi firmami, ale zmiana wersji interfejsu API jest wymagana po stronie dewelopera.

  • Sprawdzanie ważności tokena: użyj procesu działającego w tle, aby sprawdzić, czy tokeny Fitbit nie powodują błędów „Unauthorized”. Może to oznaczać, że użytkownik przeniósł swoje konto, ale Twoja aplikacja nie została jeszcze zaktualizowana.
  • Grzeczne błędy: jeśli wywołanie Fitbit OAuth nie powiedzie się, przekieruj użytkownika na niestandardową stronę „Połącz ponownie Fitbita”, która używa nowego procesu Google OAuth.