การทำงานกับข้อมูลใน Google Health API มีแกนหลักเป็นวงจรการซิงค์ข้อมูลระหว่างพื้นที่เก็บข้อมูล Google Health API ในระบบคลาวด์กับพื้นที่เก็บข้อมูลของแอปหรือแบ็กเอนด์ของคุณเอง อย่างไรก็ตาม วงจรนี้อาจมีรูปแบบต่างๆ กันไปขึ้นอยู่กับปัจจัยหลายประการ ดังนี้
- คุณเขียนข้อมูลลงใน Google Health API หรือไม่ อ่านอย่างเดียวใช่ไหม หรือทำทั้ง 2 อย่าง
- พื้นที่เก็บข้อมูลอยู่ในแอปหรืออุปกรณ์ของคุณใช่ไหม หรืออยู่ในระบบคลาวด์ของคุณเอง
- คุณต้องซิงค์ข้อมูล Google Health API ระหว่างแอปของผู้ใช้กับอุปกรณ์ที่สวมใส่ได้ใช่ไหม คุณซิงค์อุปกรณ์บ่อยแค่ไหน
- คุณทำงานกับข้อมูลประเภทใด จำนวนพื้นฐาน หน่วยวัด ชุดข้อมูลที่มีอัตราการสุ่มตัวอย่างที่แตกต่างกัน
- คุณวางแผนที่จะอ่านข้อมูลขณะที่แอปทำงานอยู่เบื้องหลังใช่ไหม
- คุณวางแผนที่จะทำงานกับข้อมูลในอดีตที่บันทึกไว้ก่อนที่แอปจะได้รับสิทธิ์จากผู้ใช้ใช่ไหม
หากต้องการทำความเข้าใจว่าทุกอย่างทำงานร่วมกันอย่างไร ให้ดูวงจรการซิงค์ของ Google Health API วงจรนี้มี 2 เวอร์ชัน ได้แก่ มาตรฐาน (อ่านและเขียน) และอ่านอย่างเดียว
วงจรการซิงค์มาตรฐาน
การผสานรวมกับ Google Health API หมายถึงการคัดลอกข้อมูลไปยังพื้นที่เก็บข้อมูลของแอปหรือแบ็กเอนด์ เราจะเรียกพื้นที่เก็บข้อมูลนี้ว่าพื้นที่เก็บข้อมูลของนักพัฒนาแอป เพื่อให้ใช้งานได้ง่ายในเอกสารนี้
"คัดลอก" ในที่นี้อาจใช้แทนกิจกรรมที่แยกกัน เช่น การอ่านจาก Google Health API (การคัดลอกไปยังพื้นที่เก็บข้อมูลของนักพัฒนาแอป) หรือการเขียนลงใน Google Health API (การคัดลอกไปยัง Google Health API) การดำเนินการเหล่านี้ซ้ำๆ ตามลำดับที่เฉพาะเจาะจงคือวงจรการซิงค์
รูปที่ 1 แสดงวงจรการซิงค์มาตรฐานที่เกี่ยวข้องกับการอ่านและการเขียน โดยไม่คำนึงถึงปัจจัยที่กล่าวถึงก่อนหน้านี้
เขียน
- เตรียมข้อมูลใหม่สำหรับการเขียน \- โอนข้อมูลจากอุปกรณ์หรือแอปภายนอก และจัดรูปแบบจุดข้อมูลให้เป็นตัวแทน JSON ที่เข้ากันได้กับประเภทข้อมูล Google Health API โปรดทราบว่าระบบไม่รองรับรหัสที่กำหนดโดยไคลเอ็นต์เองสำหรับการเขียนใน Health API ในขณะนี้ คุณอาจระบุรหัสดังกล่าวใน
POSTแต่ระบบจะไม่นำมาพิจารณา - Upsert บันทึก \- ส่งจุดข้อมูลไปยัง Google Health API โดยใช้ปลายทาง REST ใช้
POSTสำหรับการสร้างบันทึก และPATCHสำหรับการแทรกและอัปเดตบันทึกที่มีอยู่ รหัสที่จำเป็นสำหรับการดำเนินการPATCHจะมาจากดำเนินการPOSTก่อนหน้านี้ (ขั้นตอนถัดไปในวงจรก่อนหน้า) - ประมวลผลรหัสทรัพยากรที่แสดงผล \- เมื่อใช้รหัสที่สร้างโดยเซิร์ฟเวอร์ ให้แยก
และเก็บทรัพยากรที่แสดงผลจากเซิร์ฟเวอร์
nameหรือรหัสไว้ในพื้นที่เก็บข้อมูลของนักพัฒนาแอป เพื่อเปิดใช้การอัปเดต (PATCH) หรือการลบ (DELETE) ในอนาคต ดู กลยุทธ์การระบุสำหรับข้อมูลเพิ่มเติม เกี่ยวกับรหัส 2 ประเภทนี้
อ่านแล้ว
- อ่านบันทึก \- ดึงข้อมูลใหม่และการเปลี่ยนแปลงข้อมูลที่มีอยู่จาก Google Health API โดยใช้ปลายทาง REST (
GETที่มีพารามิเตอร์การค้นหาfilterและการแบ่งหน้าpageTokenหรือปลายทางการรวบรวม เช่นrollUpและdailyRollUp) หรือรับการแจ้งเตือนแบบเรียลไทม์โดยใช้การสมัครใช้บริการเว็บฮุค (projects.subscribers) การแจ้งเตือนจะระบุเพียงว่ามีข้อมูลใหม่พร้อมใช้งาน แต่ไม่ได้ระบุว่าข้อมูลจริงคืออะไร - กระทบยอดพื้นที่เก็บข้อมูลของนักพัฒนาแอป \- กระทบยอดข้อมูลใหม่และข้อมูลที่อัปเดตกับพื้นที่เก็บข้อมูลของนักพัฒนาแอป
จากนั้นวงจรนี้จะทำซ้ำตามช่วงเวลาที่เหมาะสมตามความต้องการเฉพาะของอุปกรณ์หรือแอปภายนอก โดยทั่วไปแล้ว เราขอแนะนำให้ซิงค์ข้อมูลระหว่างพื้นที่เก็บข้อมูลของคุณเองกับ Google Health API ตามลำดับนี้
กลยุทธ์การระบุ
หากคุณต้องการเขียนข้อมูลลงใน Google Health API คุณต้องเลือกกลยุทธ์การระบุทรัพยากรก่อนที่จะสร้างการผสานรวมกับ Google Health API เมื่อสร้างจุดข้อมูล (หน่วยข้อมูลพื้นฐาน)
ระบบไม่รองรับรหัสที่กำหนดโดยไคลเอ็นต์เองสำหรับการเขียนใน Health API ในขณะนี้
คุณอาจระบุรหัสดังกล่าวใน POST แต่ระบบจะไม่นำมาพิจารณา รายละเอียดเกี่ยวกับตัวเลือกนี้มีไว้เพื่อวัตถุประสงค์ในการให้ข้อมูล
- รหัสที่สร้างโดยเซิร์ฟเวอร์ (ตัวเลือกเริ่มต้น): ไคลเอ็นต์ส่งข้อมูลโดยไม่มี รหัส และแบ็กเอนด์ Google Health API จะสร้างและแสดงผลตัวระบุระบบที่ไม่ซ้ำกัน
- รหัสที่กำหนดโดยไคลเอ็นต์เอง (ต่อ AIP-133, ยัง ไม่รองรับ): แอปไคลเอ็นต์สร้างตัวระบุที่ไม่ซ้ำกัน (เช่น UUID หรือคีย์หลักของ ฐานข้อมูลภายใน) และระบุตัวระบุนั้นในเส้นทางทรัพยากรเมื่อสร้าง
ตารางต่อไปนี้เปรียบเทียบกลยุทธ์การระบุทั้ง 2 แบบเพื่อช่วยคุณเลือกแนวทางที่เหมาะสมสำหรับการผสานรวม
| ฟีเจอร์ | รหัสที่สร้างโดยเซิร์ฟเวอร์ | รหัสที่กำหนดโดยไคลเอ็นต์เอง |
|---|---|---|
| การสร้างรหัส | เซิร์ฟเวอร์สร้างรหัสระบบแบบสุ่มระหว่างการดำเนินการ POST
|
ไคลเอ็นต์สร้างรหัสที่เสถียรในเครื่อง (UUID v4 / PK ภายใน) ก่อน เขียน |
| เส้นทางทรัพยากร | .../dataPoints/{server_id} (แสดงผลในการตอบกลับ) |
.../dataPoints/{custom_id} |
| ขั้นตอนในเครื่องหลังการเขียน | ต้องระบุ ต้องจัดเก็บ server_id ที่แสดงผลในฐานข้อมูลภายในเครื่อง
เพื่อเปิดใช้การอัปเดต/การลบในอนาคต |
ไม่มี แอปเป็นเจ้าของรหัสอยู่แล้ว |
| ตารางการจับคู่รหัส | ต้องระบุ ไคลเอ็นต์ต้องดูแลรักษาการจับคู่ 2 ทาง
(local_id ↔ server_id) |
ไม่จำเป็น ไคลเอ็นต์ใช้คีย์หลักของตัวเองโดยตรง |
| ลักษณะการทำงานของการลองอีกครั้ง (เครือข่ายไม่เสถียร) | เสี่ยงต่อการเกิดรายการซ้ำ การลอง POST
อีกครั้งเมื่อหมดเวลาจะสร้างบันทึกที่ซ้ำกันด้วยรหัสเซิร์ฟเวอร์ใหม่ |
ปลอดภัยและ Idempotent การลอง POST อีกครั้งด้วย
custom_id จะป้องกันการสร้างรายการซ้ำ (แสดงผล 409
ALREADY_EXISTS) |
| การรองรับการซิงค์แบบออฟไลน์ | จำกัด ต้องรอการตอบกลับจากเซิร์ฟเวอร์เพื่อรับรหัสทรัพยากรอย่างเป็นทางการ ก่อนที่จะอ้างอิงรหัสดังกล่าว | เต็มรูปแบบ สร้างและเปลี่ยนแปลงเอนทิตีแบบออฟไลน์ได้ด้วยรหัสที่เสถียร จากนั้นซิงค์ได้อย่างราบรื่นเมื่อเชื่อมต่ออีกครั้ง |
| ข้อจำกัดด้านรูปแบบ | เซิร์ฟเวอร์จัดการทั้งหมด | ต้องเป็นไปตาม ^[a-z0-9-]{4,63}$ (ตัวอักษรและตัวเลขพิมพ์เล็ก 4-63 ตัว
และขีดกลาง) |
| กรณีที่ควรเลือก |
เลือกรหัสที่สร้างโดยเซิร์ฟเวอร์ในกรณีต่อไปนี้
|
เลือกรหัสที่กำหนดเองในกรณีต่อไปนี้
|
วงจรการซิงค์แบบอ่านอย่างเดียว
แอปที่ต้องการอ่านจาก Google Health API เท่านั้นจะต้องคัดลอกข้อมูลไปยังพื้นที่เก็บข้อมูลของนักพัฒนาแอป และจัดการส่วนการกระทบยอดของวงจร
งานเดียวกันกับที่กล่าวถึงในส่วนอ่านจะใช้ได้ที่นี่
รูปที่ 2 แสดงวงจรแบบอ่านอย่างเดียว