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ệ sức khoẻ. 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 Google Health API mới.

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

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

• Tăng cường bảo mật: Tuân thủ các phương pháp hay nhất về bảo mật của Google, phù hợp với các tiêu chuẩn về bảo mật, quyền riêng tư và danh tính của Google.
• Tính nhất quán: Loại bỏ những điểm không nhất quá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à khả năng thích ứng với 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ức năng tích hợp mới của bạn do 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ì API Fitbit Web 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ý giai đoạn "cầu 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 ứng dụng: Tạo một lớp hoặc giao diện trừu tượng cho "Dịch vụ sức khoẻ". Đ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 để đưa vào 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 tăng dần:

1. Phát hiện mã thông báo nguồn mở 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 Google OAuth: Khi người dùng nhấp vào "Cập nhật," hãy bắt đầu quy trình thư viện Google OAuth2.
3. Thay thế và thu hồi: Sau khi nhận thành công 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 được sạch sẽ.

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

Việc đồng ý lại là "vùng nguy hiểm" đối với tình trạng người dùng rời bỏ ứng dụng. Để 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 "Ưu tiên giá trị"

Đừng bắt đầu bằng câu "Chúng tôi đã cập nhật API của mình". Hãy bắt đầu bằng các 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 tính năng bảo vệ tài khoản và 2FA hàng đầu trong ngành của Google.
• Độ tin cậy: Thời gian đồng bộ hoá nhanh hơn và kết nối dữ liệu ổn định hơn.
• Giới hạn tính năng: 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 bản cập nhật.

Thời điểm 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 đồng ý lại khi người dùng đang tập thể dục 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 biểu ngữ có thể đóng.
• Giai đoạn "Cắt bỏ 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 chính thức ngừng sử dụng 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 vị trí của các nhánh logic.

Tính năng	Fitbit Web API (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) / Xác thực Google
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	Truy cập / Làm mới dành riêng cho Fitbit	Mã truy cập/Làm mới do Google cấp
Quản lý phạm vi	Quyền rộng	Quyền chi tiết / tăng dần

Xử lý sắc thái của quá trình 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 bên thứ ba, nhưng việc thay đổi phiên bản API là yêu cầu ở phía 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 biết người dùng đã di chuyển tài khoản nhưng ứng dụng của bạn chưa bắt kịp.
• Lỗi một cách suôn sẻ: 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, trang này sử dụng riêng quy trình Google OAuth mới.