Aperçu

L'API Google Health est une solution complète conçue de A à Z, qui offre aux développeurs un accès robuste à un large éventail de données de santé utilisateur avec consentement et à divers types de données. L'API Google Health utilise une nouvelle console pour enregistrer vos applications, Google OAuth 2.0, de nouveaux types de données, un nouveau schéma de point de terminaison et un nouveau format de réponse.

Ce guide est conçu pour aider les développeurs à migrer leurs applications d'API Fitbit Web existantes vers la nouvelle API Google Health. Il contient des recommandations pour assurer une migration fluide tout en conservant les utilisateurs.

Pourquoi migrer ?

Il ne s'agit pas seulement d'une mise à jour, mais d'une démarche stratégique visant à garantir la sécurité de vos applications et à les préparer aux futures avancées de la technologie de santé. Voici quelques avantages de l'utilisation de l'API Google Health :

• Accès à des données complètes : bénéficiez d'un accès robuste à un large éventail de données de santé utilisateur avec consentement et à divers types de données.
• Sécurité renforcée : respect des bonnes pratiques de sécurité de Google, conformément aux normes de Google en matière de sécurité, de confidentialité et d'identité.
• Cohérence : élimine les incohérences héritées dans les formats de données, les fuseaux horaires, les unités de mesure et la gestion des exceptions pour une expérience de développement plus intuitive.
• Évolutivité et pérennité : conçue pour évoluer afin de répondre aux besoins futurs et compatible avec les protocoles modernes tels que gRPC.

La transition de l'API Fitbit Web vers l'API Google Health implique plus que des modifications techniques. En raison du passage à une nouvelle bibliothèque OAuth, les jetons d'accès et d'actualisation existants ne peuvent pas être transférés. Les utilisateurs doivent donc donner à nouveau leur consentement à votre intégration mise à jour.

Compatibilité avec les deux méthodes de connexion

Étant donné que l'API Fitbit Web et l'API Google Health utilisent des systèmes différents pour gérer les connexions utilisateur, votre application devra temporairement prendre en charge les deux méthodes en même temps tant que les API Fitbit Web seront actives.

Au lieu que votre application demande directement des données, implémentez une couche qui détermine s'il faut communiquer avec l'API Fitbit Web ou l'API Google Health pour un utilisateur spécifique. Ainsi, le reste de votre application n'a pas à se soucier des détails.

Mettez à jour votre base de données utilisateur pour inclure un indicateur (par exemple, oauth_type) afin d'identifier le système de connexion qu'il utilise.

• Pour les nouveaux utilisateurs : configurez-les automatiquement avec la nouvelle API Google Health (oauth_type: google).
• Pour les utilisateurs existants : conservez-les sur l'API Fitbit Web jusqu'à ce qu'ils mettent à jour leur consentement (oauth_type: fitbit).

Pour éviter de perturber l'expérience utilisateur, nous vous recommandons de ne pas forcer tout le monde à se déconnecter et à se reconnecter. Au lieu de cela :

1. Lorsqu'un utilisateur qui reste connecté aux API Fitbit Web interagit avec votre application, affichez-lui une notification conviviale l'encourageant à mettre à jour sa connexion.
2. Lorsque l'utilisateur accepte l'action de mise à jour, déclenchez immédiatement le flux de connexion Google Health.
3. Une fois la connexion Google établie, enregistrez les nouveaux identifiants Google dans le profil de l'utilisateur et remplacez son indicateur oauth_type de fitbit par google. Si votre configuration le permet, déconnectez-le par programmation de l'ancien système Fitbit en révoquant ses jetons pour plus de clarté et de sécurité.

Assurer la continuité des données

Lors de la transition d'une intégration de l'ancienne API Fitbit Web vers l'API Google Health, les applications de développement doivent tenir compte d'une modification des structures d'identification des utilisateurs.

L'ancienne API Fitbit Web identifie les comptes à l'aide d'une chaîne alphanumérique de six caractères (par exemple, A1B2C3), tandis que l'API Google Health utilise un healthUserId au format d'une chaîne pouvant comporter jusqu'à 63 chiffres et caractères.

Pour combler cette lacune sans perdre le contexte utilisateur, les développeurs peuvent interroger le getIdentity point de terminaison afin d'obtenir les ID utilisateur Fitbit et Health. Ce point de terminaison renvoie une charge utile contenant à la fois le legacyUserId et le nouveau healthUserId, ce qui permet aux applications de créer dynamiquement un mappage entre les enregistrements existants et le nouveau système de compte.

Remarque : Les utilisateurs doivent disposer d'un compte Google Health pour se connecter à l'application Google Health, mais tous les utilisateurs n'en auront pas. Si un utilisateur ne dispose pas d'un compte Google Health, vous pouvez recevoir une erreur lorsque vous appelez son ID de compte à l'aide de l'API getIdentity.

Remplir les données de l'historique

Si un utilisateur ne s'authentifie pas auprès des nouveaux points de terminaison de l'API Google Health avant la désactivation des anciens points de terminaison, ses données resteront disponibles tant qu'il continuera à synchroniser son appareil avec l'application Google Health. Toutefois, il est possible que vous ayez une lacune dans les données de cet utilisateur.

Pour remplir ses données, une fois que l'utilisateur s'est authentifié à nouveau auprès des nouveaux points de terminaison, vous pouvez utiliser notre API Google Health pour remplir ses données historiques. Pour obtenir des conseils, consultez Interroger les données historiques.

Communication et timing

Pour aider vos utilisateurs à passer de leur OAuth Fitbit existant au nouvel OAuth Google, suivez ces bonnes pratiques.

Communication axée sur la valeur

Ne commencez pas par "Nous avons mis à jour notre API", mais mettez en avant les avantages de l'intégration des données Google Health dans votre application. Assurez-vous toutefois que les utilisateurs savent qu'ils doivent se réauthentifier s'ils souhaitent que leurs données soient synchronisées :

• Expliquez clairement les fonctionnalités disponibles dans votre application qui sont optimisées par l'intégration, et adaptez votre message à la façon dont un utilisateur bénéficie de ces fonctionnalités.
• Concentrez-vous sur vos fonctionnalités et fournissez des cas d'utilisation au lieu de détails techniques d'implémentation.
• Ne dites pas : "Vous ne pourrez pas vous connecter à l'API Fitbit."
• Dites plutôt : "Pour continuer à afficher des entraînements détaillés avec des données de fréquence cardiaque, donnez à nouveau votre consentement aux API Google Health."

Quand avertir les utilisateurs

Dans toutes les communications avec les utilisateurs, respectez les consignes de la marque Google Health, et utilisez des bannières, des fiches ou des alertes pouvant être ignorées.

• Ne déclenchez pas l'écran de nouveau consentement pendant qu'un utilisateur est en plein entraînement ou qu'il enregistre manuellement quelque chose.
• Ne rendez le nouveau consentement obligatoire qu'après plusieurs semaines d'avertissements, en même temps que les délais officiels de suppression de l'API Fitbit Web.
• Si un utilisateur n'a pas donné à nouveau son consentement après la date limite, fournissez un chemin de récupération fluide. Fournissez un message d'aide dans une bannière, fiche ou une info-bulle qui l'aide à comprendre pourquoi ses données sont manquantes et comment résoudre le problème.