Tổng quan

Google Health API là một API mới được xây dựng từ đầu, cho phép nhà phát triển truy vấn dữ liệu người dùng Fitbit. Đây không chỉ là một bản cập nhật mà còn là một bước đi chiến lược để đảm bảo ứng dụng của bạn an toàn, đáng tin cậy và sẵn sàng cho những tiến bộ trong tương lai về công nghệ y tế. API này hỗ trợ một bảng điều khiển mới để đăng ký ứng dụng, hỗ trợ Google OAuth 2.0, các loại dữ liệu mới, giản đồ điểm cuối mới và định dạng phản hồi mới.

Hướng dẫn này được thiết kế để giúp nhà phát triển di chuyển các ứng dụng API Fitbit Web hiện có sang API Google Health mới.

Tại sao bạn nên di chuyển?

Sau đây là những lợi ích khi sử dụng Google Health API:

• Bảo mật nâng cao: Tuân thủ các phương pháp bảo mật hay nhất của Google, phù hợp với các tiêu chuẩn của Google về bảo mật, quyền riêng tư và danh tính.
• Tính nhất quán: Loại bỏ sự không nhất quán của các phiên bản cũ trong định dạng dữ liệu, múi giờ, đơn vị đo lường và việc xử lý lỗi để mang lại trải nghiệm trực quan hơn cho nhà phát triển.
• Khả năng mở rộng và đảm bảo cho tương lai: Được thiết kế để mở rộng quy mô nhằm đáp ứng nhu cầu trong tương lai và hỗ trợ các giao thức hiện đại như gRPC.

Di chuyển người dùng

Việc di chuyển từ Fitbit Web API sang Google Health API không chỉ là một bản cập nhật kỹ thuật. Người dùng phải đồng ý lại với chế độ tích hợp mới của bạn do bạn thay đổi thư viện OAuth. Không thể chuyển mã truy cập và mã làm mới sang Google Health API và hoạt động. Để hỗ trợ việc giữ chân người dùng trong quá trình di chuyển, sau đây là một số đề xuất về kỹ thuật và chiến lược để di chuyển thành công.

Chiến lược sử dụng hai thư viện

Vì Fitbit Web API và Google Health API sử dụng các thư viện OAuth2 khác nhau, nên bạn phải quản lý một khoảng thời gian "kết nối" trong đó cả hai thư viện đều tồn tại trong cơ sở mã của bạn.

Quản lý uỷ quyền song song

• Đóng gói các ứng dụng: Tạo một lớp hoặc giao diện trừu tượng cho "Dịch vụ y tế". Điều này cho phép phần còn lại của ứng dụng yêu cầu dữ liệu mà không cần biết thư viện nào (Fitbit OAuth so với Google OAuth) đang hoạt động cho người dùng cụ thể đó.
• Cập nhật giản đồ cơ sở dữ liệu: Cập nhật bảng người dùng để thêm cờ oauth_type. Ví dụ: sử dụng fitbit cho Fitbit OAuth và google cho Google OAuth.
  • Người dùng mới: Mặc định là Google Health API và thư viện Google OAuth. Đặt oauth_type thành google.
  • Người dùng hiện tại: Tiếp tục sử dụng Fitbit Web API cho đến khi họ hoàn tất quy trình đồng ý lại. Đặt oauth_type thành fitbit.

Quy trình đồng ý lại "từng bước"

Thay vì buộc người dùng đăng xuất, hãy sử dụng phương pháp uỷ quyền gia tăng:

1. Phát hiện mã thông báo nguồn mở của Fitbit: Khi người dùng Fitbit Web API mở ứng dụng, hãy kích hoạt thông báo "Cập nhật dịch vụ".
2. Khởi chạy quy trình OAuth của Google: Khi người dùng nhấp vào "Cập nhật", hãy bắt đầu quy trình thư viện OAuth2 của Google.
3. Thay thế và thu hồi: Sau khi nhận được mã thông báo Google OAuth, hãy lưu mã thông báo đó vào hồ sơ người dùng, cập nhật oauth_type từ fitbit thành google và (nếu có thể) thu hồi mã thông báo fitbit cũ theo phương thức lập trình để giữ cho hồ sơ bảo mật của người dùng luôn sạch sẽ.

Tối đa hoá tỷ lệ giữ chân người dùng

Việc yêu cầu người dùng đồng ý lại là "vùng nguy hiểm" đối với tình trạng rời bỏ. Để ngăn người dùng rời bỏ ứng dụng, hãy làm theo các phương pháp hay nhất về trải nghiệm người dùng sau đây:

Thông tin liên lạc "Đặt giá trị lên hàng đầu"

Đừng bắt đầu bằng câu "Chúng tôi đã cập nhật API của mình". Hãy nêu bật những lợi ích của hệ thống mới do Google hỗ trợ:

• Tăng cường bảo mật: Đề cập đến khả năng bảo vệ tài khoản đầu ngành của Google và tính năng xác thực 2 yếu tố.
• Độ tin cậy: Thời gian đồng bộ hoá nhanh hơn và kết nối dữ liệu ổn định hơn.
• Phân phối có chọn lọc: Nhẹ nhàng thông báo cho người dùng rằng các tính năng và loại dữ liệu mới yêu cầu họ cập nhật.

Thời gian thông minh

• Không làm gián đoạn các tác vụ có giá trị cao: Đừng bao giờ kích hoạt màn hình yêu cầu đồng ý lại khi người dùng đang tập luyện hoặc ghi nhật ký thực phẩm.
• Giai đoạn "Nhắc nhở": Trong 30 ngày đầu tiên, hãy sử dụng một biểu ngữ có thể đóng.
• Giai đoạn "Ngừng hoàn toàn": Chỉ bắt buộc người dùng đồng ý lại sau vài tuần cảnh báo, trùng với thời hạn ngừng hoạt động chính thức của Fitbit Web API.

So sánh quy trình di chuyển

Sự khác biệt rõ ràng về mặt hình ảnh giữa quy trình cũ và quy trình mới giúp nhà phát triển hiểu được nơi phân nhánh logic.

Tính năng	Fitbit Web API (Phiên bản cũ)	Google Health API (Google-Identity)
Thư viện xác thực	Nguồn mở tiêu chuẩn	Dịch vụ nhận dạng của Google (GIS) / Google Auth
Tài khoản Người dùng	Thông tin đăng nhập cũ của Fitbit	Tài khoản Google
Loại mã thông báo	Quyền truy cập / làm mới dành riêng cho Fitbit	Mã truy cập/Mã làm mới do Google phát hành
Quản lý phạm vi	Quyền truy cập rộng	Quyền chi tiết / Quyền gia tăng

Xử lý sắc thái của việc di chuyển tài khoản

Theo tài liệu của Fitbit, người dùng di chuyển tài khoản sang Google thường không mất ngay các kết nối với bên thứ ba, nhưng việc thay đổi phiên bản API là yêu cầu bắt buộc đối với nhà phát triển.

• Kiểm tra tính hợp lệ của mã thông báo: Sử dụng backgroundworker để kiểm tra xem mã thông báo Fitbit có gặp lỗi "Không được phép" hay không. Điều này có thể cho thấy người dùng đã di chuyển tài khoản của họ nhưng ứng dụng của bạn chưa bắt kịp.
• Lỗi duyên dáng: Nếu lệnh gọi Fitbit OAuth không thành công, hãy chuyển hướng người dùng đến trang "Kết nối lại Fitbit" tuỳ chỉnh, trong đó sử dụng cụ thể quy trình Google OAuth mới.