Quản lý dữ liệu trong Google Health API

Về cơ bản, việc xử lý dữ liệu trong Google Health API là một chu trình đồng bộ hoá dữ liệu giữa kho dữ liệu Google Health API trên đám mây và kho dữ liệu ứng dụng hoặc phụ trợ của riêng bạn. Tuy nhiên, chu kỳ này có thể có nhiều hình thức tuỳ thuộc vào nhiều yếu tố:

• Bạn có đang ghi dữ liệu vào Google Health API không? Chỉ đọc? Hay làm cả hai?
• Kho dữ liệu của bạn có phải là kho dữ liệu cục bộ trên ứng dụng hoặc thiết bị không? Hoặc trong đám mây của riêng bạn?
• Bạn có cần đồng bộ hoá dữ liệu Google Health API giữa ứng dụng của người dùng và một thiết bị đeo không? Bạn đồng bộ hoá thiết bị bao lâu một lần?
• Bạn đang làm việc với những loại dữ liệu nào? Số lượt xem cơ bản? Đơn vị đo lường? Loạt phim có tốc độ lấy mẫu khác nhau?
• Bạn có dự định đọc dữ liệu trong khi ứng dụng của bạn đang ở chế độ nền không?
• Bạn có dự định xử lý dữ liệu trong quá khứ được ghi lại trước khi ứng dụng của bạn nhận được quyền của người dùng không?

Để hiểu cách tất cả những điều này kết hợp với nhau, hãy xem vòng đời đồng bộ hoá của Google Health API. Có hai phiên bản của vòng đời này: tiêu chuẩn (đọc và ghi) và chỉ đọc.

Vòng đời đồng bộ hoá tiêu chuẩn

Hình 1: Vòng đời đồng bộ hoá tiêu chuẩn trong Google Health API

Việc tích hợp với Google Health API có nghĩa là bạn sẽ sao chép dữ liệu vào một ứng dụng hoặc kho dữ liệu phụ trợ. Để dễ sử dụng trong tài liệu này, chúng ta sẽ gọi kho dữ liệu này là kho dữ liệu dành cho nhà phát triển.

"Sao chép" ở đây có thể thay thế cho bất kỳ hoạt động riêng biệt nào, chẳng hạn như đọc từ Google Health API (sao chép vào kho dữ liệu của nhà phát triển) hoặc ghi vào Google Health API (sao chép vào Google Health API). Việc thực hiện lặp lại các thao tác này theo một thứ tự cụ thể là vòng đời đồng bộ hoá.

Hình 1 minh hoạ vòng đời đồng bộ hoá tiêu chuẩn liên quan đến các thao tác đọc và ghi, bất kể yếu tố nào đã đề cập trước đó.

Viết

1. Chuẩn bị dữ liệu mới để ghi – Chuyển dữ liệu từ một thiết bị hoặc ứng dụng bên ngoài và định dạng các điểm dữ liệu thành biểu thị JSON tương thích với các kiểu dữ liệu của Google Health API. Xin lưu ý rằng API Health hiện không hỗ trợ các mã nhận dạng tuỳ chỉnh do ứng dụng chỉ định cho các thao tác ghi. Bạn có thể cung cấp các mã nhận dạng như vậy trong POST, nhưng chúng sẽ bị bỏ qua.
2. Chèn và cập nhật bản ghi – Gửi điểm dữ liệu đến Google Health API bằng cách sử dụng các điểm cuối REST. Sử dụng POST để tạo bản ghi và PATCH để chèn và cập nhật bản ghi hiện có. Các mã nhận dạng cần thiết cho thao tác PATCH sẽ đến từ thao tác POST trước đó (bước tiếp theo trong một chu kỳ trước đó).
3. Xử lý mã nhận dạng tài nguyên được trả về – Khi sử dụng mã nhận dạng do máy chủ tạo, hãy trích xuất và duy trì tài nguyên name hoặc mã nhận dạng do máy chủ trả về trong kho dữ liệu của nhà phát triển để cho phép các bản cập nhật (PATCH) hoặc lượt xoá (DELETE) trong tương lai. Hãy xem Chiến lược nhận dạng để biết thêm thông tin về hai loại này.

Đọc

1. Đọc bản ghi – Tìm nạp dữ liệu mới và các thay đổi đối với dữ liệu hiện có trong Google Health API bằng cách sử dụng các điểm cuối REST (GET có các tham số truy vấn filter và phân trang pageToken hoặc các điểm cuối tổng hợp như rollUp và dailyRollUp), hoặc nhận thông báo theo thời gian thực bằng cách sử dụng Đăng ký webhook (projects.subscribers). Thông báo chỉ cho biết có dữ liệu mới, chứ không cho biết dữ liệu thực tế là gì.
2. Điều chỉnh datastore của nhà phát triển – Điều chỉnh dữ liệu mới và dữ liệu đã cập nhật cho datastore của nhà phát triển.

Sau đó, chu kỳ này sẽ lặp lại theo các khoảng thời gian thích hợp tuỳ theo nhu cầu cụ thể của các thiết bị hoặc ứng dụng bên ngoài. Đây thường là thứ tự mà chúng tôi đề xuất để đồng bộ hoá dữ liệu giữa kho dữ liệu của riêng bạn và Google Health API.

Chiến lược nhận dạng

Nếu muốn ghi dữ liệu vào Google Health API, trước khi tạo mối tích hợp với Google Health API, bạn phải chọn một chiến lược nhận dạng tài nguyên khi tạo điểm dữ liệu (đơn vị dữ liệu cơ bản).

Health API hiện không hỗ trợ mã nhận dạng do ứng dụng khách chỉ định cho các thao tác ghi. Bạn có thể cung cấp những mã nhận dạng như vậy trong POST, nhưng chúng sẽ bị bỏ qua. Thông tin chi tiết về lựa chọn này được cung cấp ở đây chỉ nhằm mục đích tham khảo.

1. Mã nhận dạng do máy chủ tạo (lựa chọn mặc định): Ứng dụng gửi dữ liệu mà không có mã nhận dạng và phần phụ trợ Google Health API sẽ tạo và trả về một giá trị nhận dạng hệ thống duy nhất.
2. Mã nhận dạng tuỳ chỉnh do ứng dụng khách chỉ định (theo AIP-133, chưa được hỗ trợ): Ứng dụng khách tạo một giá trị nhận dạng duy nhất (ví dụ: khoá chính UUID hoặc cơ sở dữ liệu cục bộ) và cung cấp giá trị nhận dạng đó trong đường dẫn tài nguyên khi tạo.

Bảng sau đây so sánh cả hai chiến lược nhận dạng để giúp bạn chọn phương pháp phù hợp cho hoạt động tích hợp:

Tính năng	Mã nhận dạng do máy chủ tạo	Mã nhận dạng tuỳ chỉnh do khách hàng chỉ định
Tạo mã nhận dạng	Máy chủ tạo mã nhận dạng hệ thống ngẫu nhiên trong quá trình thực thi POST.	Ứng dụng tạo mã nhận dạng ổn định cục bộ (UUID phiên bản 4 / khoá chính nội bộ) trước khi ghi.
Đường dẫn tài nguyên	.../dataPoints/{server_id} (trả về trong phản hồi)	.../dataPoints/{custom_id}
Post-Write Local Step	Bắt buộc. Phải lưu trữ server_id đã trả về trong DB cục bộ để cho phép cập nhật/xoá trong tương lai.	Không có. Ứng dụng đã sở hữu mã nhận dạng này.
Bảng liên kết mã nhận dạng	Bắt buộc. Ứng dụng phải duy trì mối liên kết hai chiều (local_id ↔ server_id).	Không cần thiết. Ứng dụng sử dụng trực tiếp khoá chính của riêng mình.
Hành vi thử lại (Mạng yếu)	Rủi ro về nội dung trùng lặp. Việc thử lại POST đã hết thời gian chờ sẽ tạo một bản ghi trùng lặp có mã máy chủ mới.	An toàn và bất biến. Thử lại POST với cùng một custom_id sẽ ngăn việc tạo trùng lặp (trả về 409 ALREADY_EXISTS).
Hỗ trợ đồng bộ hoá khi không có mạng	Bị hạn chế. Phải đợi phản hồi của máy chủ để lấy mã nhận dạng tài nguyên chính thức trước khi tham chiếu đến các mã nhận dạng đó.	Đầy. Bạn có thể tạo và thay đổi các thực thể ở chế độ ngoại tuyến bằng mã nhận dạng ổn định, sau đó đồng bộ hoá liền mạch khi kết nối lại.
Các quy tắc ràng buộc về định dạng	Do máy chủ xử lý hoàn toàn.	Phải tuân theo ^[a-z0-9-]{4,63}$ (4–63 ký tự chữ và số viết thường và dấu gạch ngang).
Khi nào nên chọn	Chọn mã do máy chủ tạo nếu: Ứng dụng của bạn chỉ ghi / chỉ thêm (ví dụ: gửi dữ liệu đo từ xa hoặc số bước không bao giờ được cập nhật hoặc xoá sau này). Ứng dụng của bạn không duy trì cơ sở dữ liệu cố định cục bộ của các điểm dữ liệu riêng lẻ. Bạn thích sự đơn giản mà không cần quản lý các ràng buộc xác thực chuỗi (chẳng hạn như ký tự 4-63).	Chọn mã nhận dạng tuỳ chỉnh nếu: Bạn vận hành một ứng dụng đồng bộ hoá hai chiều để đọc, ghi và cập nhật hồ sơ sức khoẻ trên các thiết bị. Ứng dụng của bạn có một cơ sở dữ liệu cục bộ (chẳng hạn như Room hoặc SQLite) lưu trữ các bản ghi có khoá chính cục bộ. Người dùng của bạn ghi lại dữ liệu khi không có mạng hoặc khi kết nối di động không ổn định và cần có các lần thử lại an toàn. Bạn muốn loại bỏ các bảng liên kết mã nhận dạng giữa cơ sở dữ liệu phụ trợ và API.

Vòng đời đồng bộ hoá chỉ có thể đọc

Hình 2: Vòng đời đồng bộ hoá chỉ đọc trong Google Health API

Một ứng dụng chỉ có ý định đọc dữ liệu từ Google Health API phải sao chép dữ liệu vào kho dữ liệu của nhà phát triển và xử lý phần điều chỉnh của vòng đời.

Các nhiệm vụ tương tự trong phần Đọc cũng áp dụng ở đây.

Hình 2 minh hoạ vòng đời chỉ đọc.