Google Health API adalah API baru yang dibuat dari awal dan memungkinkan developer membuat kueri data pengguna Fitbit. Ini bukan hanya update, tetapi juga langkah strategis untuk memastikan aplikasi Anda aman, andal, dan siap untuk kemajuan teknologi kesehatan di masa mendatang. API ini mendukung konsol baru untuk mendaftarkan aplikasi Anda, dukungan Google OAuth 2.0, jenis data baru, skema endpoint baru, dan format respons baru.
Panduan ini dirancang untuk membantu developer memigrasikan aplikasi Fitbit Web API yang ada ke Google Health API baru.
Mengapa Anda harus bermigrasi?
Manfaat menggunakan Google Health API adalah:
- Keamanan yang Ditingkatkan: Kepatuhan terhadap praktik terbaik keamanan Google, yang selaras dengan standar keamanan, privasi, dan identitas Google.
- Konsistensi: Menghilangkan inkonsistensi lama dalam format data, zona waktu, unit pengukuran, dan penanganan error untuk pengalaman developer yang lebih intuitif.
- Skalabilitas &Persiapan untuk Masa Depan: Dirancang untuk diskalakan guna memenuhi permintaan di masa mendatang dan mendukung protokol modern seperti gRPC.
Memigrasikan Pengguna
Migrasi dari Fitbit Web API ke Google Health API lebih dari sekadar update teknis. Pengguna Anda harus memberikan izin ulang untuk integrasi baru Anda karena perubahan library OAuth. Token akses dan token refresh tidak dapat ditransfer ke Google Health API dan berfungsi. Untuk membantu retensi pengguna selama migrasi, berikut beberapa saran teknis dan strategis untuk migrasi yang berhasil.
Strategi Library Ganda
Karena Fitbit Web API dan Google Health API menggunakan library OAuth2 yang berbeda, Anda harus mengelola periode "penghubung" saat kedua library ada dalam codebase Anda.
Pengelolaan Otorisasi Paralel
- Mengenkapsulasi Klien: Buat lapisan abstraksi atau antarmuka untuk "Layanan Kesehatan" Anda. Hal ini memungkinkan aplikasi Anda lainnya meminta data tanpa mengetahui library mana (Fitbit OAuth versus Google OAuth) yang aktif untuk pengguna tertentu tersebut.
- Update Skema Database: Perbarui tabel pengguna Anda untuk menyertakan
oauth_typeflag. Misalnya, gunakanfitbituntuk Fitbit OAuth dangoogleuntuk Google OAuth.- Pengguna Baru: Tetapkan Google Health API dan library Google OAuth
sebagai default. Tetapkan
oauth_typekegoogle. - Pengguna yang Ada: Tetap gunakan Fitbit Web API hingga mereka menyelesaikan
alur pemberian izin ulang. Tetapkan
oauth_typekefitbit.
- Pengguna Baru: Tetapkan Google Health API dan library Google OAuth
sebagai default. Tetapkan
Alur Pemberian Izin Ulang "Step-Up"
Daripada memaksa logout, gunakan pendekatan otorisasi inkremental:
- Mendeteksi Token Open Source Fitbit: Saat pengguna Fitbit Web API membuka aplikasi, picu notifikasi "Update Layanan".
- Meluncurkan Alur Google OAuth: Saat pengguna mengklik "Update", mulai alur library Google OAuth2.
- Mengganti & Mencabut: Setelah token Google OAuth berhasil diterima, simpan ke profil pengguna, perbarui
oauth_typedarifitbitkegoogle, dan (jika memungkinkan) cabut tokenfitbitlama secara terprogram untuk menjaga profil keamanan pengguna tetap bersih.
Memaksimalkan Retensi Pengguna
Pemberian izin ulang adalah "zona bahaya" untuk churn. Untuk mencegah pengguna meninggalkan aplikasi, ikuti praktik terbaik UX berikut:
Komunikasi "Mengutamakan Nilai"
Jangan mulai dengan "Kami memperbarui API kami". Mulai dengan manfaat sistem baru yang didukung Google:
- Keamanan yang Ditingkatkan: Sebutkan perlindungan akun dan 2FA Google yang terkemuka di industri.
- Keandalan: Waktu sinkronisasi yang lebih cepat dan koneksi data yang lebih stabil.
- Pembatasan Fitur: Beri tahu pengguna secara halus bahwa fitur baru dan jenis data memerlukan update.
Waktu yang Tepat
- Jangan Mengganggu Tugas Bernilai Tinggi: Jangan pernah memicu layar pemberian izin ulang saat pengguna sedang berolahraga atau mencatat makanan.
- Fase "Peringatan": Selama 30 hari pertama, gunakan banner yang dapat ditutup.
- Fase "Batas Akhir": Hanya jadikan pemberian izin ulang sebagai wajib setelah beberapa minggu peringatan, yang bertepatan dengan batas waktu penghentian Fitbit Web API resmi.
Perbandingan Alur Migrasi
Perbedaan visual yang jelas antara alur lama dan baru membantu developer memahami tempat logika bercabang.
| Fitur | Fitbit Web API (Lama) | Google Health API (Identitas Google) |
| Library Auth | Open Source Standar | Google Identity Services (GIS) / Google Auth |
| Akun Pengguna | Kredensial Lama Fitbit | Akun Google |
| Jenis Token | Akses / Refresh Khusus Fitbit | Token Akses/Refresh yang dikeluarkan Google |
| Pengelolaan Cakupan | Izin luas | Izin terperinci / inkremental |
Menangani Nuansa Migrasi Akun
Menurut dokumentasi Fitbit, pengguna yang memigrasikan akun mereka ke Google umumnya tidak langsung kehilangan koneksi pihak ketiga mereka, tetapi mengubah versi API adalah persyaratan sisi developer.
- Memeriksa Validitas Token: Gunakan backgroundworker untuk memeriksa apakah token Fitbit gagal dengan error "Tidak Sah". Hal ini mungkin menunjukkan bahwa pengguna telah memigrasikan akun mereka, tetapi aplikasi Anda belum mengikuti.
- Kegagalan yang Elegan: Jika panggilan Fitbit OAuth gagal, alihkan pengguna ke halaman "Hubungkan Kembali Fitbit" kustom yang secara khusus menggunakan alur Google OAuth baru.