نمای کلی

رابط برنامه‌نویسی کاربردی گوگل هلث (Google Health API) یک رابط برنامه‌نویسی کاربردی جدید است که از پایه ساخته شده و به توسعه‌دهندگان اجازه می‌دهد تا داده‌های کاربران فیت‌بیت (Fitbit) را جستجو کنند. این فقط یک به‌روزرسانی نیست، بلکه یک حرکت استراتژیک برای اطمینان از ایمن، قابل اعتماد بودن و آماده بودن برنامه‌های شما برای پیشرفت‌های آینده در فناوری سلامت است. این رابط برنامه‌نویسی کاربردی از یک کنسول جدید برای ثبت برنامه‌های شما، پشتیبانی از Google OAuth 2.0، انواع داده‌های جدید، طرحواره نقطه پایانی جدید و قالب پاسخ جدید پشتیبانی می‌کند.

این راهنما به گونه‌ای طراحی شده است که به توسعه‌دهندگان کمک کند تا برنامه‌های Fitbit Web API موجود خود را به Google Health API جدید منتقل کنند.

چرا باید مهاجرت کرد؟

مزایای استفاده از API گوگل هلث عبارتند از:

  • امنیت پیشرفته : انطباق با بهترین شیوه‌های امنیتی گوگل، همسو با استانداردهای امنیتی، حریم خصوصی و هویت گوگل.
  • سازگاری : ناسازگاری‌های قدیمی در قالب‌های داده‌ها، مناطق زمانی، واحدهای اندازه‌گیری و مدیریت خطا را برای یک تجربه توسعه‌دهنده شهودی‌تر از بین می‌برد.
  • مقیاس‌پذیری و آینده‌نگر : طراحی شده برای مقیاس‌پذیری جهت پاسخگویی به نیازهای آینده و پشتیبانی از پروتکل‌های مدرن مانند gRPC.

کاربران خود را منتقل کنید

مهاجرت از API وب Fitbit به API گوگل هلث چیزی بیش از یک به‌روزرسانی فنی است. کاربران شما باید به دلیل تغییر کتابخانه OAuth، دوباره با ادغام جدید شما موافقت کنند. انتقال توکن‌های دسترسی و توکن‌های به‌روزرسانی به 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 تنظیم کنید.

جریان «افزایشی» رضایت مجدد

به جای اجبار به خروج از سیستم، از رویکرد افزایشی مجوز استفاده کنید:

  1. تشخیص توکن متن‌باز Fitbit : وقتی یک کاربر Fitbit Web API برنامه را باز می‌کند، یک اعلان «به‌روزرسانی سرویس» نمایش داده می‌شود.
  2. راه‌اندازی جریان OAuth گوگل : وقتی کاربر روی «به‌روزرسانی» کلیک می‌کند، جریان کتابخانه OAuth2 گوگل آغاز می‌شود.
  3. جایگزینی و ابطال : پس از دریافت موفقیت‌آمیز توکن OAuth گوگل، آن را در پروفایل کاربر ذخیره کنید، oauth_type از fitbit به google به‌روزرسانی کنید و (در صورت امکان) توکن قدیمی fitbit را به صورت برنامه‌نویسی ابطال کنید تا پروفایل امنیتی کاربر پاک بماند.

به حداکثر رساندن نرخ حفظ کاربر

رضایت مجدد، «منطقه خطر» برای ریزش کاربر است. برای جلوگیری از ترک اپلیکیشن توسط کاربران، این بهترین شیوه‌های تجربه کاربری را دنبال کنید:

ارتباط «ارزش-محور»

با عبارت «ما API خود را به‌روزرسانی کردیم» شروع نکنید. با مزایای سیستم جدید تحت پشتیبانی گوگل شروع کنید:

  • امنیت پیشرفته : به محافظت از حساب‌های کاربری و احراز هویت دو مرحله‌ای پیشرو در صنعت گوگل اشاره کنید.
  • قابلیت اطمینان : زمان همگام‌سازی سریع‌تر و اتصالات داده پایدارتر.
  • به‌روزرسانی ویژگی‌ها : به آرامی به کاربران اطلاع دهید که ویژگی‌ها و انواع داده‌های جدید نیاز به به‌روزرسانی دارند.

زمان‌بندی هوشمند

  • وظایف با ارزش بالا را قطع نکنید : هرگز صفحه رضایت مجدد را در حالی که کاربر در حال تمرین یا ثبت اطلاعات غذایی است، فعال نکنید.
  • مرحله «هل دادن» : ​​برای 30 روز اول، از یک بنر قابل رد کردن استفاده کنید.
  • مرحله «قطع کامل دسترسی» : فقط پس از چند هفته هشدار، رضایت مجدد را اجباری کنید، که مصادف با مهلت‌های رسمی منسوخ شدن Fitbit Web API است.

مقایسه جریان مهاجرت

یک تمایز بصری واضح بین جریان‌های قدیمی و جدید به توسعه‌دهندگان کمک می‌کند تا بفهمند منطق از کجا منشعب می‌شود.

ویژگی رابط برنامه‌نویسی کاربردی وب فیت‌بیت (قدیمی) رابط برنامه‌نویسی کاربردی گوگل هلث (گوگل-هویت)
کتابخانه Auth استاندارد متن‌باز سرویس‌های هویت گوگل (GIS) / گوگل آث
حساب‌های کاربری اعتبارنامه‌های قدیمی فیت‌بیت حساب گوگل
نوع توکن دسترسی/رفرش مخصوص فیت‌بیت توکن‌های دسترسی/به‌روزرسانی صادر شده توسط گوگل
مدیریت محدوده مجوزهای گسترده مجوزهای جزئی/افزایشی

مدیریت جزئیات انتقال حساب کاربری

طبق مستندات Fitbit، کاربرانی که حساب خود را به گوگل منتقل می‌کنند، معمولاً بلافاصله اتصالات شخص ثالث خود را از دست نمی‌دهند، اما تغییر نسخه API یک الزام از طرف توسعه‌دهنده است.

  • بررسی اعتبار توکن : از یک ابزار پس‌زمینه برای بررسی اینکه آیا توکن‌های Fitbit با خطای «غیرمجاز» از کار می‌افتند یا خیر، استفاده کنید. این ممکن است نشان دهد که کاربر حساب خود را منتقل کرده است اما برنامه شما هنوز به آن متصل نشده است.
  • شکست‌های دلپذیر : اگر فراخوانی Fitbit OAuth با شکست مواجه شود، کاربر را به صفحه سفارشی "Reconnect Fitbit" که به طور خاص از جریان جدید Google OAuth استفاده می‌کند، هدایت کنید.