סקירה כללית

‫Google Health API הוא API חדש שנבנה מאפס ומאפשר למפתחים לשלוח שאילתות לגבי נתוני משתמשים ב-Fitbit. זה לא רק עדכון, אלא מהלך אסטרטגי שמטרתו לוודא שהאפליקציות שלכם בטוחות, אמינות ומוכנות להתפתחויות עתידיות בטכנולוגיות בתחום הבריאות. ה-API תומך במסוף חדש לרישום האפליקציות, בתמיכה ב-Google OAuth 2.0, בסוגי נתונים חדשים, בסכימת נקודות קצה חדשה ובפורמט תגובה חדש.

המדריך הזה נועד לעזור למפתחים להעביר את האפליקציות הקיימות שלהם ב-Fitbit Web API אל Google Health API החדש.

למה כדאי לבצע את ההעברה

היתרונות של שימוש ב-Google Health API:

• אבטחה משופרת: עמידה בשיטות המומלצות של Google לאבטחה, בהתאם לתקני האבטחה, הפרטיות והזהות של Google.
• עקביות: הממשק החדש מבטל אי-עקביות שקיימת בגרסאות קודמות בפורמטים של נתונים, באזורי זמן, ביחידות מידה ובטיפול בשגיאות, כדי לספק חוויית פיתוח אינטואיטיבית יותר.
• יכולת הרחבה והיערכות לעתיד: הממשק נועד להתרחב כדי לעמוד בדרישות עתידיות, והוא תומך בפרוטוקולים מודרניים כמו 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 עבור Fitbit OAuth וב-google עבור Google OAuth.
  • משתמשים חדשים: ברירת המחדל היא Google Health API וספריית Google OAuth. מגדירים את oauth_type לערך google.
  • משתמשים קיימים: ממשיכים להשתמש ב-Fitbit Web API עד שהם משלימים את תהליך ההסכמה מחדש. מגדירים את oauth_type לערך fitbit.

תהליך קבלת הסכמה חוזרת (Step-Up)

במקום לכפות יציאה מהחשבון, כדאי להשתמש בגישה של הרשאה מצטברת:

1. זיהוי טוקן קוד פתוח של Fitbit: כשמשתמש ב-Fitbit Web API פותח את האפליקציה, מופעלת הודעה על עדכון שירות.
2. הפעלת תהליך OAuth של Google: כשהמשתמש לוחץ על 'עדכון', מפעילים את תהליך ספריית OAuth2 של Google.
3. החלפה וביטול: אחרי קבלת אסימון Google OAuth, שומרים אותו בפרופיל המשתמש, מעדכנים את oauth_type מ-fitbit ל-google, ואם אפשר, מבטלים את אסימון fitbit הישן באופן אוטומטי כדי לשמור על פרופיל האבטחה של המשתמש.

מקסום שימור המשתמשים

בקשת הסכמה חוזרת היא "אזור הסכנה" שבו יש סיכון לנטישה. כדי למנוע מצב שבו משתמשים נוטשים את האפליקציה, כדאי לפעול לפי השיטות המומלצות הבאות לשיפור חוויית המשתמש:

התקשורת שמתמקדת בערך

אל תתחילו במילים 'עדכנו את ה-API שלנו'. כדאי להתחיל עם היתרונות של המערכת החדשה שנתמכת על ידי Google:

• אבטחה משופרת: כדאי לציין את ההגנה על החשבון ואת האימות הדו-שלבי של Google, שהם מהמובילים בתחום.
• מהימנות: זמני סנכרון מהירים יותר וחיבורי נתונים יציבים יותר.
• הגבלת גישה לתכונות: כדאי להודיע למשתמשים בצורה ברורה שנדרש עדכון כדי להשתמש בתכונות חדשות ובסוגי נתונים חדשים.

תזמון חכם

• אל תפריעו למשימות חשובות: אל תציגו את מסך הבקשה להסכמה מחדש בזמן שהמשתמש באמצע אימון כושר או בזמן שהוא מתעד את האוכל שהוא אוכל.
• השלב 'תזכורת': במהלך 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 הוא דרישה בצד המפתח.

• בדיקת תוקף הטוקן: משתמשים ב-backgroundworker כדי לבדוק אם טוקנים של Fitbit נכשלים עם שגיאות מסוג Unauthorized. יכול להיות שהמשתמש העביר את החשבון שלו, אבל האפליקציה שלכם לא עודכנה בהתאם.
• כשלים שאינם גורמים להפסקת הפעולה: אם קריאת Fitbit OAuth נכשלת, צריך להפנות את המשתמש לדף מותאם אישית של 'התחברות מחדש ל-Fitbit' שמשתמש ספציפית בתהליך החדש של Google OAuth.