Google Health API は、デベロッパーが Fitbit ユーザーデータをクエリできるように、ゼロから構築された新しい API です。これは単なるアップデートではなく、アプリの安全性と信頼性を確保し、将来のヘルスケア技術の進歩に対応するための戦略的な動きです。この API は、アプリを登録するための新しいコンソール、Google OAuth 2.0 のサポート、新しいデータ型、新しいエンドポイント スキーマ、新しいレスポンス形式をサポートしています。
このガイドは、既存の Fitbit Web API アプリを新しい Google Health API に移行するデベロッパーを支援することを目的としています。
移行が必要な理由
Google Health API を使用するメリットは次のとおりです。
- セキュリティの強化: Google のセキュリティに関するベスト プラクティスに準拠し、 Google のセキュリティ、プライバシー、ID の標準に沿っています。
- 一貫性: データ形式、タイム ゾーン、測定単位、エラー処理における従来の不整合を解消し、デベロッパー エクスペリエンスをより直感的にします。
- スケーラビリティと将来性: 将来の需要に対応できるように設計されており、gRPC などの最新のプロトコルをサポートしています。
ユーザーを移行する
Fitbit Web API から Google Health API への移行は、単なる技術的な更新ではありません。OAuth ライブラリの変更により、ユーザーは新しい統合に再度同意する必要があります。アクセス トークンと更新トークンを Google Health API に転送して機能させることはできません。移行中のユーザー維持を支援するため、移行を成功させるための技術的および戦略的な提案をいくつかご紹介します。
デュアル ライブラリ戦略
Fitbit Web API と Google Health API では異なる OAuth2 ライブラリを使用するため、コードベースに両方のライブラリが存在する「ブリッジング」期間を管理する必要があります。
並列認証管理
- クライアントのカプセル化: 「ヘルスサービス」の抽象化レイヤまたはインターフェースを作成します。これにより、アプリの残りの部分では、特定のユーザーに対してどのライブラリ（Fitbit OAuth と Google OAuth）がアクティブであるかを意識せずにデータをリクエストできます。
- データベース スキーマの更新: ユーザー テーブルを更新して、
oauth_typeフラグを含めます。たとえば、Fitbit OAuth にはfitbit、Google OAuth にはgoogleを使用します。- 新規ユーザー: デフォルトで Google Health API と Google OAuth
ライブラリを使用します。
oauth_typeをgoogleに設定します。 - 既存のユーザー: 再同意フローが完了するまで、Fitbit Web API を使用します。
oauth_typeをfitbitに設定します。
- 新規ユーザー: デフォルトで Google Health API と Google OAuth
ライブラリを使用します。
「ステップアップ」再同意フロー
強制的にログアウトさせるのではなく、段階的な認証 アプローチを使用します。
- Fitbit オープンソース トークンを検出: Fitbit Web API ユーザーが アプリを開くと、「サービス アップデート」通知がトリガーされます。
- Google OAuth フローを開始: ユーザーが [更新] をクリックすると、 Google OAuth2 ライブラリ フローが開始されます。
- 置換と取り消し: Google OAuth トークンが正常に受信されたら、ユーザー プロファイルに保存し、
oauth_typeをfitbitからgoogleに更新します。可能であれば、古いfitbitトークンをプログラムで取り消して、ユーザーのセキュリティ プロファイルをクリーンな状態に保ちます。
ユーザー維持率を最大化する
再同意は、離脱の「危険地帯」です。ユーザーがアプリを放棄しないようにするには、次の UX のベスト プラクティスに従ってください。
「価値優先」のコミュニケーション
「API を更新しました」というメッセージから始めないでください。Google がサポートする新しいシステムのメリットから始めます。
- セキュリティの強化: Google の業界をリードするアカウント 保護と 2FA について説明します。
- 信頼性: 同期時間の短縮とデータ接続の安定化。
- 機能ゲーティング: 新しい機能と データ型にはアップデートが必要であることをユーザーに丁寧に伝えます。
スマート タイミング
- 価値の高いタスクを中断しない: ユーザーがワークアウト中や食事の記録中に、再同意 画面をトリガーしないでください。
- 「ナッジ」フェーズ: 最初の 30 日間は、閉じることのできるバナーを使用します。
- 「ハードカットオフ」フェーズ: 数週間の警告の後、Fitbit Web API の正式な非推奨期限に合わせて、再同意を必須にします。
移行フローの比較
新旧のフローを明確に区別することで、デベロッパーはロジックが分岐する場所を把握できます。
| 機能 | Fitbit Web API（レガシー） | Google Health API（Google Identity） |
| 認証ライブラリ | 標準オープンソース | Google Identity Services（GIS）/ Google Auth |
| ユーザー アカウント | Fitbit レガシー認証情報 | Google アカウント |
| トークンのタイプ | Fitbit 固有のアクセス / 更新 | Google が発行したアクセス/更新トークン |
| スコープ管理 | 広範な権限 | きめ細かい権限 / 段階的な権限 |
アカウント移行のニュアンスを処理する
Fitbit のドキュメントによると、アカウントを Google に移行するユーザーは通常、サードパーティ接続をすぐに失うことはありませんが、API バージョンの変更はデベロッパー側の要件です。
- トークンの有効性を確認: バックグラウンド ワーカーを使用して、Fitbit トークンが「Unauthorized」エラーで失敗していないかどうかを確認します。これは、ユーザーがアカウントを移行したものの、アプリが追いついていないことを示している可能性があります。
- グレースフルな失敗: Fitbit OAuth の呼び出しが失敗した場合は、新しい Google OAuth フローを具体的に使用するカスタムの [Fitbit に再接続] ページにユーザーをリダイレクトします。