Exemple d'implémentation

Pour migrer de l'ancienne API Fitbit Web vers l'API Google Health, vous passerez des bibliothèques OAuth2 générales à la bibliothèque Google Auth. Vous trouverez ci-dessous une suggestion d'architecture et une implémentation de pseudo-code écrite en JavaScript pour gérer cet état de "double bibliothèque".

1. Commutateur de middleware

Étant donné que vous ne pouvez pas migrer tous les utilisateurs en même temps, votre backend doit déterminer quelle bibliothèque utiliser en fonction de l'apiVersion actuelle de l'utilisateur stockée dans votre base de données.

Mise en œuvre

const { OAuth2Client } = require('google-auth-library');
const FitbitV1Strategy = require('fitbit-oauth2-library').Strategy;

// 1. Initialize the Google Health API Client
const GHAClient = new OAuth2Client(
  process.env.GOOGLE_CLIENT_ID,
  process.env.GOOGLE_CLIENT_SECRET,
  process.env.REDIRECT_URI
);

// 2. Create a Unified Fetcher
async function fetchSteps(user) {
  if (user.apiVersion === 4) {
    // ---- GOOGLE OAUTH LIBRARY LOGIC ----
    GHAClient.setCredentials({ refresh_token: user.refreshToken });
    const url = 'GET https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints';
    const res = await GHAClient.request({ url });
    return res.data;
  } else {
    // ---- FITBIT WEB API LEGACY LOGIC ----
    // Use your existing Fitbit open-source library logic here
    return callLegacyV1Api(user.accessToken);
  }
}

2. Migrer le flux d'expérience utilisateur

Pour maximiser la fidélisation, utilisez un "Interruption et mise à niveau" modèle. Ainsi, l'utilisateur n'est pas obligé de se reconnecter tant qu'il n'est pas déjà engagé dans l'application.

Logique de redirection

Lorsqu'un utilisateur de l'API Fitbit Web accède à une fonctionnalité spécifique, déclenchez la migration :

app.get('/dashboard', async (req, res) => {
  const user = await db.users.find(req.user.id);

  if (user.apiVersion === 1) {
    // Render a "soft" migration page explaining the Google transition
    return res.render('migrate-to-google', {
      title: "Keep your data syncing",
      message: "Fitbit is moving to Google accounts. Re-connect now to stay updated."
    });
  }

  const data = await fetchSteps(user);
  res.render('dashboard', { data });
});

3. Principales transitions techniques

Lorsque vous écrivez vos scripts de migration JavaScript, gardez à l'esprit les différences suivantes :

Fonctionnalité	API Fitbit Web (ancienne)	API Google Health (identité Google)
Point de terminaison du jeton	https://api.fitbit.com/oauth2/token	https://oauth2.googleapis.com/token
Bibliothèque d'authentification	Open Source standard	Authentification Google
Champ d'application	activité	https://www.googleapis.com/auth/googlehealth.activity_and_fitness
ID utilisateur	ID Fitbit encodé renvoyé dans la réponse /oauth2/token	ID utilisateur renvoyé à partir du point de terminaison users.getIdentity

4. Check-list de fidélisation

• Persistance de la session : ne supprimez pas l'ancienne session de l'API Fitbit Web de l'utilisateur tant que l'access_token de l'API Google Health n'a pas été validé et enregistré dans votre base de données.
• Révocation automatique : une fois la migration de l'API Google Health terminée, utilisez une requête POST au point de terminaison de révocation Fitbit hérité : https://api.fitbit.com/oauth2/revoke. Ainsi, l'utilisateur ne voit pas d'autorisations d'application "en double" dans ses paramètres Fitbit.
• Gestion des erreurs : si un appel Fitbit renvoie une erreur 401 non autorisée, redirigez automatiquement vers le flux OAuth de Google au lieu d'afficher un message d'erreur.