Google Health API הוא פתרון מקיף שנבנה מאפס, ומספק למפתחים גישה חזקה למגוון רחב של נתוני בריאות של משתמשים שנתנו את הסכמתם, ולסוגים שונים של נתונים. ב-Google Health API נעשה שימוש במסוף חדש לרישום האפליקציות, ב-Google OAuth 2.0, בסוגי נתונים חדשים, בסכימת נקודות קצה חדשה ובפורמט תגובה חדש.
המדריך הזה מיועד לעזור למפתחים להעביר את האפליקציות הקיימות שלהם ב-Fitbit Web API ל-Google Health API החדש. הוא כולל המלצות להבטחת מעבר חלק תוך שמירה על המשתמשים.
למה כדאי לבצע את ההעברה
זה לא רק עדכון, אלא מהלך אסטרטגי שמטרתו לוודא שהאפליקציות שלכם מאובטחות ומוכנות להתפתחויות עתידיות בטכנולוגיות בתחום הבריאות. אלה כמה מהיתרונות של השימוש ב-Google Health API:
- גישה לנתונים מקיפים: תקבלו גישה חזקה למגוון רחב של נתוני בריאות של משתמשים שנתנו את הסכמתם, ולסוגי נתונים מגוונים.
- אבטחה משופרת: עמידה בשיטות המומלצות של Google לאבטחה, בהתאם לתקני האבטחה, הפרטיות והזהות של Google.
- עקביות: הממשק החדש מבטל אי-עקביות שקיימת בגרסה הקודמת בפורמטים של נתונים, באזורי זמן, ביחידות מידה ובטיפול בשגיאות, וכך משפר את חוויית המפתחים.
- יכולת הרחבה והתאמה לעתיד: המערכת מתוכננת להתרחב כדי לעמוד בדרישות עתידיות, והיא תומכת בפרוטוקולים מודרניים כמו gRPC.
המעבר מ-Fitbit Web API ל-Google Health API כולל יותר משינויים טכניים. בגלל המעבר לספריית OAuth חדשה, אי אפשר להעביר טוקנים קיימים של גישה ורענון, ולכן המשתמשים צריכים לתת הסכמה מחדש לשילוב המעודכן.
תמיכה בשתי שיטות הכניסה
ממשק Fitbit Web API וממשק Google Health API משתמשים במערכות שונות לטיפול בהתחברות של משתמשים. לכן, בזמן שממשקי Fitbit Web API עדיין פעילים, האפליקציה שלכם תצטרך לתמוך בשתי השיטות בו-זמנית.
במקום שהאפליקציה תבקש נתונים ישירות, כדאי להטמיע שכבה שמחליטה אם לפנות אל Fitbit Web API או אל Google Health API עבור משתמש ספציפי, כך ששאר האפליקציה לא צריכה לדאוג לגבי הפרטים.
מעדכנים את מסד נתוני המשתמשים כדי לכלול דגל (לדוגמה, oauth_type)
לזיהוי מערכת הכניסה שבה הם משתמשים.
- למשתמשים חדשים: המערכת מגדירה אותם באופן אוטומטי באמצעות Google Health API החדש (
oauth_type: google). - למשתמשים קיימים: כדאי להשאיר אותם ב-Fitbit Web API עד שהם יעדכנו את ההסכמה שלהם (
oauth_type: fitbit).
כדי לא לשבש את חוויית המשתמש, אנחנו ממליצים לא לחייב את כולם להתנתק ולהתחבר מחדש. במקום זאת:
- כשמשתמש שנשאר מחובר ל-Fitbit Web APIs יוצר אינטראקציה עם האפליקציה שלכם, כדאי להציג לו הודעה ידידותית שמעודדת אותו לעדכן את החיבור.
- כשהמשתמש מאשר את פעולת העדכון, מפעילים מיד את תהליך ההתחברות ל-Google Health.
- אחרי שהכניסה לחשבון Google מסתיימת בהצלחה, שומרים את פרטי הכניסה החדשים לחשבון Google בפרופיל של המשתמש ומעבירים את הדגל
oauth_typeשלו מ-fitbitל-google. אם ההגדרה מאפשרת זאת, כדאי להוציא אותם מהמערכת הישנה של Fitbit באופן אוטומטי על ידי ביטול האסימונים שלהם, כדי לשמור על הסדר והאבטחה.
שמירה על המשכיות הנתונים
כשמעבירים שילוב מ-Fitbit Web API מדור קודם ל-Google Health API, אפליקציות למפתחים צריכות להתחשב בשינוי במבני זיהוי המשתמש.
ב-Fitbit Web API מדור קודם, החשבונות מזוהים באמצעות מחרוזת אלפאנומרית בת 6 תווים (למשל A1B2C3), ואילו ב-Google Health API נעשה שימוש ב-healthUserId בפורמט של מחרוזת עם עד 63 ספרות ותווים.
כדי לגשר על הפער הזה בלי לאבד את הקשר למשתמש, מפתחים יכולים לשלוח שאילתה לנקודת הקצה getIdentity כדי לקבל את מזהי המשתמש ב-Fitbit וב-Health.
נקודת הקצה הזו מחזירה מטען ייעודי (payload) שמכיל את legacyUserId ואת healthUserId החדש, וכך מאפשרת לאפליקציות ליצור באופן דינמי מיפוי בין רשומות קיימות לבין מערכת החשבונות החדשה.
מילוי חוזר של נתונים היסטוריים
אם משתמש לא יאמת את עצמו בנקודות הקצה החדשות של Google Health API לפני שנקודות הקצה מדור קודם יושבתו, הנתונים שלו עדיין יהיו זמינים כל עוד הוא ימשיך לסנכרן את המכשיר שלו עם אפליקציית Google Health. עם זאת, יכול להיות שיהיה פער בנתונים של המשתמש הזה.
כדי למלא מחדש את הנתונים, אחרי שהמשתמש מאמת מחדש את הזהות שלו בנקודות הקצה החדשות, אפשר להשתמש ב-Google Health API כדי למלא מחדש את הנתונים ההיסטוריים שלו. הוראות מפורטות זמינות במאמר בנושא שאילתות של נתונים היסטוריים.
תקשורת ותזמון
כדי לעזור למשתמשים לעבור מ-OAuth הקיים של Fitbit ל-OAuth החדש של Google, מומלץ לפעול לפי השיטות המומלצות הבאות.
תקשורת שמתמקדת בערך
אל תתחילו במילים "עדכנו את ה-API שלנו", אלא תתחילו ביתרונות של שילוב נתוני Google Health באפליקציה שלכם, אבל הקפידו ליידע את המשתמשים שהם צריכים לבצע אימות מחדש אם הם רוצים שהנתונים שלהם יסתנכרנו:
- להסביר בצורה ברורה אילו תכונות זמינות באפליקציה בזכות השילוב, ולהתאים את ההודעה ליתרונות שהמשתמש יכול להפיק מהתכונות האלה.
- כדאי להתמקד בתכונות ולספק תרחישי שימוש במקום פרטים טכניים על ההטמעה.
- אל תגידו: "לא תהיה לך אפשרות להתחבר ל-Fitbit API".
- כן כדאי לומר: "כדי להמשיך לראות אימוני כושר מפורטים עם נתוני דופק, צריך להביע מחדש את ההסכמה ל-Google Health APIs".
מתי לשלוח התראות למשתמשים
בכל התקשורת עם המשתמשים, צריך לפעול בהתאם להנחיות המותג של Google Health ולהשתמש בהודעות, בכרטיסים או בהתראות שאפשר לסגור.
- אין להפעיל את מסך בקשת ההסכמה מחדש בזמן שמשתמש נמצא באמצע אימון כושר או בזמן שהוא רושם משהו באופן ידני.
- הפיכת קבלת ההסכמה מחדש לחובה תתבצע רק אחרי כמה שבועות של אזהרות, במקביל למועדים הרשמיים להוצאה משימוש של Fitbit Web API.
- אם משתמש לא הביע הסכמה מחדש אחרי תאריך היעד הסופי, צריך לספק דרך שחזור חלקה. כדאי להציג הודעת עזרה בבאנר, בכרטיס או בתיבת מידע, כדי לעזור למשתמשים להבין למה הנתונים שלהם חסרים ואיך אפשר לתקן את זה.