Обзор

API Google Health — это новый API, разработанный с нуля, позволяющий разработчикам запрашивать данные пользователей Fitbit. Это не просто обновление, а стратегический шаг, призванный обеспечить безопасность, надежность и готовность ваших приложений к будущим достижениям в области медицинских технологий. API поддерживает новую консоль для регистрации приложений, поддержку Google OAuth 2.0, новые типы данных, новую схему конечных точек и новый формат ответов.

Данное руководство призвано помочь разработчикам перевести существующие приложения Fitbit Web API на новый Google Health API.

Почему вам стоит эмигрировать?

Преимущества использования API Google Health заключаются в следующем:

  • Повышенная безопасность : соответствие передовым методам обеспечения безопасности Google, а также стандартам Google в области безопасности, конфиденциальности и идентификации.
  • Согласованность : устраняет устаревшие несоответствия в форматах данных, часовых поясах, единицах измерения и обработке ошибок, обеспечивая более интуитивно понятный интерфейс для разработчиков.
  • Масштабируемость и перспективность : разработано с учетом масштабируемости для удовлетворения будущих потребностей и поддерживает современные протоколы, такие как gRPC.

Перенесите своих пользователей

Переход с веб-API Fitbit на API Google Health — это не просто техническое обновление. Вашим пользователям потребуется повторно дать согласие на новую интеграцию из-за изменения библиотеки OAuth. Передача токенов доступа и токенов обновления в API Google Health и их последующая работа невозможны. Чтобы помочь в удержании пользователей во время миграции, ниже приведены некоторые технические и стратегические рекомендации для успешного перехода.

Стратегия двойной библиотеки

Поскольку Fitbit Web API и Google Health API используют разные библиотеки OAuth2, вам необходимо обеспечить "промежуточный" период, в течение которого обе библиотеки будут присутствовать в вашем коде.

Параллельное управление авторизацией

  • Инкапсуляция клиентов : Создайте абстрактный слой или интерфейс для вашей «службы здоровья». Это позволит остальной части вашего приложения запрашивать данные, не зная, какая библиотека (Fitbit OAuth или Google OAuth) активна для конкретного пользователя.
  • Обновление схемы базы данных : обновите таблицу пользователей, добавив флаг oauth_type . Например, используйте fitbit для аутентификации Fitbit OAuth и google для аутентификации Google OAuth.
    • Для новых пользователей : по умолчанию используется Google Health API и библиотека Google OAuth. Установите oauth_type в google .
    • Существующие пользователи : Оставайтесь в системе Fitbit Web API до завершения процесса повторного согласия. Установите oauth_type в fitbit .

Процедура повторного согласия "поэтапного повышения".

Вместо принудительного выхода из системы используйте поэтапный подход к авторизации :

  1. Обнаружение токена открытого исходного кода Fitbit : когда пользователь Fitbit Web API открывает приложение, запускается уведомление об обновлении сервиса.
  2. Запуск потока Google OAuth : Когда пользователь нажимает кнопку «Обновить», запустите поток библиотеки Google OAuth2.
  3. Замена и аннулирование : После успешного получения токена Google OAuth сохраните его в профиле пользователя, обновите oauth_type с fitbit на google и (если возможно) программно аннулируйте старый токен fitbit , чтобы сохранить чистоту профиля безопасности пользователя.

Максимальное удержание пользователей

Повторное согласие — это «опасная зона» для оттока пользователей. Чтобы предотвратить уход пользователей из приложения, следуйте этим рекомендациям по UX:

Коммуникация, ставящая ценности на первое место.

Не начинайте с фразы "Мы обновили наш API". Начните с преимуществ новой системы, поддерживаемой Google:

  • Повышенная безопасность : упомяните лучшую в отрасли защиту учетных записей и двухфакторную аутентификацию от Google.
  • Надежность : Более быстрая синхронизация и более стабильное соединение для передачи данных.
  • Ограничение доступа к функциям : Ненавязчиво сообщите пользователям, что для добавления новых функций и типов данных требуется обновление.

Умный тайминг

  • Не прерывайте выполнение важных задач : никогда не запускайте экран повторного согласия, когда пользователь находится в процессе тренировки или регистрации потребляемой пищи.
  • Этап «постепенного воздействия» : В течение первых 30 дней используйте закрывающийся баннер.
  • Этап «жесткого прекращения» : повторное согласие должно стать обязательным только после нескольких недель предупреждений, что совпадает с официальными сроками прекращения поддержки веб-API Fitbit.

Сравнение миграционных потоков

Четкое визуальное разграничение старого и нового сценариев помогает разработчикам понять, где происходит разветвление логики.

Особенность Веб-API Fitbit (устаревшая версия) API Google Health (Google-Identity)
Библиотека аутентификации Стандартный открытый исходный код Google Identity Services (GIS) / Google Auth
Учетные записи пользователей Устаревшие учетные данные Fitbit Аккаунт Google
Тип токена Доступ/Обновление, специфичные для Fitbit Токены доступа/обновления, выданные Google.
Управление объемом работ Широкие права доступа Детализированные/постепенные разрешения

Устранение нюансов миграции учетных записей

Согласно документации Fitbit, пользователи, переносящие свои учетные записи в Google, как правило, не теряют сразу же свои подключения к сторонним сервисам, но изменение версии API является требованием разработчиков.

  • Проверка действительности токена : используйте фоновый процесс (backgroundworker), чтобы проверить, не выдают ли токены Fitbit ошибки "Несанкционированный доступ". Это может указывать на то, что пользователь перенес свою учетную запись, но ваше приложение еще не обновилось.
  • Корректная обработка ошибок : Если запрос OAuth к Fitbit завершается неудачей, перенаправьте пользователя на специальную страницу «Переподключение Fitbit», которая использует новый процесс аутентификации Google OAuth.