סקירה כללית

‫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, ולכן צריך לנהל תקופת מעבר שבה שתי הספריות קיימות בבסיס הקוד.

ניהול הרשאות מקביל

• הוספת שכבת הפשטה ללקוחות: יוצרים שכבת הפשטה או ממשק עבור Health Service. כך שאר האפליקציה יכולה לבקש נתונים בלי לדעת איזו ספרייה (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: כשהמשתמש לוחץ על 'עדכון', מפעילים את תהליך הספרייה של Google OAuth2.
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
חשבונות משתמש	פרטי כניסה מדור קודם של Fitbit	חשבון Google
סוג הטוקן	גישה או רענון ספציפיים ל-Fitbit	טוקנים של גישה או רענון שהונפקו על ידי Google
ניהול היקף	הרשאות רחבות	הרשאות פרטניות / מצטברות

התמודדות עם ניואנסים בהעברת חשבונות

לפי התיעוד של Fitbit, משתמשים שמעבירים את החשבון שלהם ל-Google בדרך כלל לא מאבדים את החיבורים שלהם לצדדים שלישיים באופן מיידי, אבל שינוי גרסת ה-API הוא דרישה בצד המפתח.

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