نمای کلی

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

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

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

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

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

انتقال از رابط برنامه‌نویسی وب Fitbit به رابط برنامه‌نویسی Google Health چیزی بیش از اصلاحات فنی است. به دلیل تغییر به یک کتابخانه جدید OAuth، توکن‌های دسترسی و به‌روزرسانی موجود قابل انتقال نیستند و کاربران ملزم به رضایت مجدد برای ادغام به‌روزرسانی‌شده شما هستند.

پشتیبانی از هر دو روش ورود

از آنجایی که Fitbit Web API و Google Health API از سیستم‌های متفاوتی برای مدیریت ورود کاربران استفاده می‌کنند، تا زمانی که Fitbit Web APIها هنوز فعال هستند، برنامه شما موقتاً باید از هر دو روش به طور همزمان پشتیبانی کند.

به جای اینکه برنامه شما مستقیماً درخواست داده کند، لایه‌ای را پیاده‌سازی کنید که تصمیم بگیرد برای یک کاربر خاص با Fitbit Web API یا Google Health API ارتباط برقرار کند، تا بقیه برنامه شما نیازی به نگرانی در مورد جزئیات نداشته باشد.

پایگاه داده کاربران خود را به‌روزرسانی کنید تا یک پرچم (مثلاً oauth_type ) برای شناسایی سیستم ورود به سیستمی که از آن استفاده می‌کنند، در آن قرار گیرد.

  • برای کاربران جدید : آنها را به طور خودکار با API جدید Google Health ( oauth_type: google ) تنظیم کنید.
  • برای کاربران فعلی : آنها را تا زمانی که رضایت خود را به‌روزرسانی کنند ( oauth_type: fitbit )، در Fitbit Web API نگه دارید.

برای جلوگیری از اختلال در تجربه کاربری، توصیه می‌کنیم همه را مجبور به خروج و ورود مجدد نکنید. در عوض:

  1. وقتی کاربری که به APIهای وب Fitbit متصل است و با برنامه شما تعامل می‌کند، یک اعلان دوستانه به او نشان دهید و او را تشویق کنید که اتصال خود را به‌روزرسانی کند.
  2. وقتی کاربر اقدام به‌روزرسانی را پذیرفت، همان لحظه جریان ورود به سیستم Google Health را فعال کنید.
  3. پس از موفقیت‌آمیز بودن ورود به سیستم گوگل، اطلاعات کاربری جدید گوگل را در پروفایل کاربر ذخیره کنید و پرچم oauth_type آنها را از fitbit به google تغییر دهید. اگر تنظیمات شما اجازه می‌دهد، با لغو توکن‌های آنها ، به صورت برنامه‌نویسی شده آنها را از سیستم قدیمی Fitbit خارج کنید تا همه چیز مرتب و ایمن بماند.

تضمین تداوم داده‌ها

هنگام انتقال یکپارچه‌سازی از رابط برنامه‌نویسی قدیمی وب Fitbit به رابط برنامه‌نویسی Google Health، برنامه‌های توسعه‌دهنده باید تغییر در ساختارهای شناسایی کاربر را در نظر بگیرند.

رابط برنامه‌نویسی کاربردی وب قدیمی Fitbit حساب‌ها را با استفاده از یک رشته الفبایی-عددی ۶ کاراکتری (مانند A1B2C3 ) شناسایی می‌کند، در حالی که رابط برنامه‌نویسی کاربردی Google Health از یک شناسه healthUserId با فرمت رشته‌ای تا ۶۳ رقم و کاراکتر استفاده می‌کند.

برای پر کردن این شکاف بدون از دست دادن اطلاعات کاربر، توسعه‌دهندگان می‌توانند از نقطه پایانی getIdentity برای دریافت شناسه‌های کاربری Fitbit و Health استفاده کنند. این نقطه پایانی یک payload حاوی legacyUserId و healthUserId جدید را برمی‌گرداند و به برنامه‌ها این امکان را می‌دهد که به صورت پویا یک نگاشت بین رکوردهای موجود و سیستم حساب جدید ایجاد کنند.

داده‌های تاریخی را دوباره پر کنید

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

برای تکمیل مجدد داده‌های آنها، پس از احراز هویت مجدد کاربر در نقاط انتهایی جدید، می‌توانید از API Google Health ما برای تکمیل مجدد داده‌های تاریخی آنها استفاده کنید. برای راهنمایی به بخش «پرسش داده‌های تاریخی» مراجعه کنید.

ارتباط و زمان‌بندی

برای کمک به کاربرانتان در انتقال از Fitbit OAuth موجود خود به Google OAuth جدید، این شیوه‌های برتر را دنبال کنید.

ارتباط با اولویت ارزش

با عبارت «ما API خود را به‌روزرسانی کردیم» شروع نکنید، بلکه با مزایای ادغام داده‌های Google Health در برنامه خود شروع کنید، اما مطمئن شوید که آنها آگاه هستند که اگر می‌خواهند داده‌هایشان همگام‌سازی شود، باید دوباره احراز هویت شوند:

  • به طور واضح توضیح دهید که چه ویژگی‌هایی در برنامه شما وجود دارد که از طریق این ادغام پشتیبانی می‌شوند و پیام خود را متناسب با چگونگی بهره‌مندی کاربر از آن ویژگی‌ها تنظیم کنید.
  • روی ویژگی‌های خود تمرکز کنید و به جای جزئیات پیاده‌سازی فنی، موارد استفاده را ارائه دهید.
  • نگویید : «شما نمی‌توانید به رابط برنامه‌نویسی کاربردی فیت‌بیت متصل شوید.»
  • بگویید : «برای ادامه مشاهده تمرینات دقیق با داده‌های ضربان قلب، دوباره با APIهای Google Health موافقت کنید.»

چه زمانی به کاربران اطلاع دهیم

در تمام ارتباطات کاربری، به دستورالعمل‌های برند Google Health پایبند باشید و از بنرها، کارت‌ها یا هشدارهای قابل رد کردن استفاده کنید.

  • وقتی کاربر در حال تمرین است یا به صورت دستی چیزی را ثبت می‌کند، صفحه‌ی رضایت مجدد را فعال نکنید.
  • فقط پس از چند هفته هشدار، که مصادف با مهلت‌های رسمی منسوخ شدن Fitbit Web API است، رضایت مجدد را اجباری کنید.
  • اگر کاربری پس از قطع دسترسی سخت، دوباره رضایت نداده است، یک مسیر بازیابی مناسب ارائه دهید. یک پیام راهنما در قالب یک بنر ، کارت یا راهنمای ابزار ارائه دهید که به آنها کمک کند تا دلیل از دست رفتن اطلاعاتشان و نحوه رفع آن را درک کنند.