Обзор

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

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

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

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

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

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

Поддерживаются оба способа входа в систему.

Поскольку веб-API Fitbit и API Google Health используют разные системы для обработки авторизации пользователей, пока веб-API Fitbit активны, вашему приложению временно потребуется поддерживать оба метода одновременно.

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

Обновите базу данных пользователей, добавив флаг (например, oauth_type ), который будет указывать, какую систему авторизации они используют.

  • Для новых пользователей : автоматическая настройка доступа к новому API Google Health ( oauth_type: google ).
  • Для существующих пользователей : сохраните их доступ к веб-API Fitbit до тех пор, пока они не обновят свои данные согласия ( oauth_type: fitbit ).

Чтобы избежать нарушения пользовательского опыта, мы рекомендуем не заставлять всех выходить из системы и входить заново. Вместо этого:

  1. Когда пользователь, остающийся подключенным к веб-API Fitbit, взаимодействует с вашим приложением, покажите ему дружелюбное уведомление, предлагающее обновить подключение.
  2. Когда пользователь подтвердит действие обновления, немедленно запустите процесс входа в Google Health.
  3. После успешного входа через Google сохраните новые учетные данные Google в профиле пользователя и измените флаг oauth_type с fitbit на google . Если ваша система это позволяет, программно выведите пользователя из старой системы Fitbit, аннулировав его токены , чтобы обеспечить порядок и безопасность.

Обеспечьте непрерывность передачи данных.

При переходе от устаревшего веб-API Fitbit к API Google Health разработчикам необходимо учитывать изменение структуры идентификации пользователей в своих приложениях.

В устаревшем веб-API Fitbit учетные записи идентифицируются с помощью 6-символьной буквенно-цифровой строки (например, A1B2C3 ), тогда как API Google Health использует healthUserId отформатированный как строка, содержащая до 63 цифр и символов.

Чтобы устранить этот пробел, не теряя контекста пользователя, разработчики могут использовать конечную точку getIdentity для получения идентификаторов пользователей Fitbit и Health . Эта конечная точка возвращает полезную нагрузку, содержащую как legacyUserId , так и новый healthUserId , что позволяет приложениям динамически создавать сопоставление между существующими записями и новой системой учетных записей.

Восполнение исторических данных

Если пользователь не пройдет аутентификацию в новых конечных точках API Google Health до того, как устаревшие конечные точки будут отключены, его данные все равно будут доступны, пока он продолжает синхронизировать свое устройство с приложением Google Health. Однако у вас может возникнуть пробел в данных по этому пользователю.

Чтобы восстановить данные пользователя после повторной аутентификации на новых конечных точках, вы можете использовать наш API Google Health для восстановления исторических данных. См. раздел «Запрос исторических данных» для получения дополнительной информации.

Коммуникация и сроки

Чтобы помочь вашим пользователям перейти с существующей аутентификации Fitbit OAuth на новую аутентификацию Google OAuth, следуйте этим рекомендациям.

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

Не начинайте с фразы "Мы обновили наш API", а сосредоточьтесь на преимуществах интеграции данных Google Health в ваше приложение, но убедитесь, что пользователи знают о необходимости повторной аутентификации для синхронизации своих данных:

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

Когда следует уведомлять пользователей

Во всех коммуникациях с пользователями придерживайтесь рекомендаций по использованию фирменного стиля Google Health и используйте закрываемые баннеры, карточки или оповещения.

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