หน้านี้ให้ภาพรวมของข้อกำหนด REST API พร้อมด้วยดัชนีงาน Google Health API ที่ใช้กันทั่วไปและตัวอย่างของแต่ละงาน
ข้อกำหนด REST API
Google Health API เป็นไปตามมาตรฐานข้อเสนอแนะเพื่อปรับปรุง Google API (AIP) โดยเฉพาะ AIP-127 (การแปลงรหัส HTTP และ gRPC) และ AIP-131 ถึง AIP-135 (เมธอดมาตรฐาน) มาตรฐานเหล่านี้กำหนดวิธีจับคู่ข้อมูลจากข้อความ Proto กับคำขอ HTTP
พารามิเตอร์การค้นหา
ใช้พารามิเตอร์การค้นหาเมื่อข้อมูลเป็นส่วนหนึ่งของ URL โดยส่วนใหญ่จะใช้สำหรับคำขอ GET (การดึงข้อมูลทรัพยากร) หรือคำขอ LIST (การกรอง/การแบ่งหน้า) แต่ยังใช้สำหรับการดำเนินการ DELETE ด้วย
- ตำแหน่ง: เพิ่มต่อท้าย URL หลังจาก
? - ไวยากรณ์: คู่คีย์-ค่าที่คั่นด้วย
& - การจับคู่: ระบบจะจับคู่ทุกช่องในข้อความคำขอที่ไม่ได้เป็นส่วนหนึ่งของเทมเพลตเส้นทาง URL กับพารามิเตอร์การค้นหา
- เหมาะสำหรับ: ประเภทข้อมูลอย่างง่าย (สตริง, จำนวนเต็ม, Enum) และช่องที่ซ้ำ
ไวยากรณ์ตัวอย่าง
GET https://health.googleapis.com/v4/users/me/dataTypes/data-type/dataPoints?page_size=10&filter=data_type.interval.start_time >= "2025-10-01T00:00:00Z"
เนื้อความของคำขอ
ใช้เนื้อความของคำขอเมื่อข้อมูลแก้ไขสถานะของทรัพยากรหรือมีขนาดใหญ่เกินกว่าจะใส่ใน URL โดยปกติเนื้อความจะเป็นการแสดง JSON ของทรัพยากรเอง ซึ่งมักใช้สำหรับการดำเนินการ POST, PATCH และ PUT
- ตำแหน่ง: ภายในเพย์โหลด HTTP (ไม่ปรากฏใน URL)
- ไวยากรณ์: จัดรูปแบบเป็นออบเจ็กต์ JSON
- การจับคู่: กำหนดไว้ในคำอธิบายประกอบ
google.api.httpbody: "*"หมายความว่าข้อความทั้งหมดคือเนื้อความbody: "resource_name"หมายความว่าเฉพาะช่องที่เฉพาะเจาะจงใน Proto คือ เนื้อความ
- เหมาะสำหรับ: ออบเจ็กต์ที่ซับซ้อน ข้อความที่ซ้อนกัน และข้อมูลที่ละเอียดอ่อน
ไวยากรณ์ตัวอย่าง
POST https://health.googleapis.com/v4/users/me/dataTypes/data-type/dataPoints:rollUp
Content-Type: application/json
{
"range": {
"startTime": "2025-11-05T00:00:00Z",
"endTime": "2025-11-13T00:00:00Z"
},
"windowSize": "3600s"
}กรณีไฮบริด
ในเมธอด Update ที่เป็นไปตาม AIP-134 หรือการดำเนินการ PATCH ระบบจะใช้ทั้ง 2 อย่าง
URL จะมีชื่อทรัพยากร เนื้อความจะมีข้อมูลทรัพยากรที่อัปเดต และพารามิเตอร์การค้นหา (โดยปกติคือ update_mask) จะระบุช่องที่จะเปลี่ยนแปลง
PATCH https://health.googleapis.com/v4/projects/project-id/subscribers/subscriber-id
Content-Type: application/json
{
"endpointUri": "https://myapp.com/new-webhooks/health"
}
ความแตกต่างหลักๆ โดยย่อ
| ฟีเจอร์ | พารามิเตอร์การค้นหา | เนื้อความของคำขอ |
|---|---|---|
| หลักเกณฑ์ของ AIP | ใช้สำหรับการค้นหา การกรอง และการดำเนินการอ่าน | ใช้สำหรับการดำเนินการเขียน |
| การมองเห็น | ปรากฏในประวัติการเข้าชมของเบราว์เซอร์และบันทึกของเซิร์ฟเวอร์ | ซ่อนจาก URL |
| ความซับซ้อน | จำกัดไว้ที่โครงสร้างแบบแบนหรือแบบซ้ำ | รองรับออบเจ็กต์ JSON ที่ซ้อนกันหลายชั้น |
| การเข้ารหัส | ต้องเข้ารหัส URL (เช่น ช่องว่างจะกลายเป็น %20) |
การเข้ารหัส JSON มาตรฐาน |
วันที่
วันที่ทั้งหมดใน Google Health API จะแสดงในรูปแบบ YYYY-MM-DD Nutrition API รองรับมาตรฐาน ISO-8601 สำหรับค่าวันที่โดยมีเงื่อนไขดังนี้
- ปี 4 หลัก
YYYY - ค่าปีในช่วง 0000-9999
- ไม่มีการบังคับใช้ข้อจำกัดวันที่เริ่มต้นที่ระบุโดยมาตรฐาน ISO-8601 หรือ Epoch อื่นๆ
ส่วนหัว
การเรียกใช้ปลายทาง Google Health API ต้องใช้ส่วนหัวและโทเค็นเพื่อการเข้าถึงที่เหมาะสม เราขอแนะนำให้ใช้ส่วนหัวต่อไปนี้สำหรับคำขอ GET และ POST
Authorization: Bearer access-token Accept: application/json
ดัชนีงาน API
ส่วนนี้มีดัชนีงาน Google Health API ที่ใช้กันทั่วไปและตัวอย่างของแต่ละงาน
รับรหัสผู้ใช้ Fitbit หรือ Google
หลังจากที่ผู้ใช้ให้ความยินยอมผ่าน Google OAuth 2.0 การตอบกลับโทเค็นจะไม่มีรหัสผู้ใช้ Fitbit หรือ Google หากต้องการรับรหัสผู้ใช้ ให้เรียกปลายทาง
getIdentity getIdentity
จะแสดงทั้งรหัสผู้ใช้เดิมของ Fitbit และรหัสผู้ใช้ Google
เราขอแนะนำให้คุณเรียกปลายทาง getIdentity และจัดเก็บรหัสผู้ใช้ทั้ง 2 รายการทันทีที่ผู้ใช้ใหม่ให้ความยินยอมผ่าน OAuth ซึ่งจะช่วยให้การผสานรวมของคุณมีความเข้ากันได้ทั้งในปัจจุบันและอนาคต
ตัวอย่าง
ส่งคำขอ
GET https://health.googleapis.com/v4/users/me/identity Authorization: Bearer access-token Accept: application/json
คำตอบ
{
"name": "users/me/identity",
"legacyUserId": "A1B2C3",
"healthUserId": "111111256096816351"
}รับข้อมูลระหว่างวันหรือข้อมูลโดยละเอียดที่รวบรวมตลอดทั้งวัน
ใช้ list
ปลายทาง สำหรับประเภทข้อมูลที่เฉพาะเจาะจงเพื่อรับข้อมูลระหว่างวันหรือข้อมูลโดยละเอียดที่รวบรวมตลอดทั้งวันในช่วงเวลาที่
รองรับสำหรับประเภทข้อมูลนั้น
ตัวอย่าง
ส่งคำขอ
GET https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints Authorization: Bearer access-token Accept: application/json
คำตอบ
{
"dataPoints": [
{
"dataSource": {
"recordingMethod": "PASSIVELY_MEASURED",
"device": {
"manufacturer": "",
"displayName": "Charge 6"
},
"platform": "FITBIT"
},
"steps": {
"interval": {
"startTime": "2026-03-04T07:05:00Z",
"startUtcOffset": "0s",
"endTime": "2026-03-04T07:06:00Z",
"endUtcOffset": "0s",
"civilStartTime": {
"date": {
"year": 2026,
"month": 3,
"day": 4
},
"time": {
"hours": 7,
"minutes": 5
}
},
"civilEndTime": {
"date": {
"year": 2026,
"month": 3,
"day": 4
},
"time": {
"hours": 7,
"minutes": 6
}
}
},
"count": "40"
}
},
...
],
"nextPageToken": "Xm5h-6L0viZxIlRuWjx5bmvy98zj85uG34tuMn16mu2pntsnZI32iqhq"
}กรองข้อมูลตามเวลาเริ่มต้นของช่วงเวลา
ใช้ปลายทาง list กับพารามิเตอร์ filter เพื่อกรองข้อมูลตามเวลาหรือช่วงเวลา
ตัวอย่าง
ส่งคำขอ
GET https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints?filter=steps.interval.civil_start_time >= "2026-03-04T00:00:00" Authorization: Bearer access-token Accept: application/json
คำตอบ
{
"dataPoints": [
{
"dataSource": {
"recordingMethod": "PASSIVELY_MEASURED",
"device": {
"manufacturer": "",
"displayName": "Charge 6"
},
"platform": "FITBIT"
},
"steps": {
"interval": {
"startTime": "2026-03-04T07:05:00Z",
"startUtcOffset": "0s",
"endTime": "2026-03-04T07:06:00Z",
"endUtcOffset": "0s",
"civilStartTime": {
"date": {
"year": 2026,
"month": 3,
"day": 4
},
"time": {
"hours": 7,
"minutes": 5
}
},
"civilEndTime": {
"date": {
"year": 2026,
"month": 3,
"day": 4
},
"time": {
"hours": 7,
"minutes": 6
}
}
},
"count": "40"
}
...
],
"nextPageToken": "Xm5h-6L0viZxIlRuQjp5bml1bZ4ve2dhNmZvMnt4Yn7qIGQhbHN3YQ"
}กรองข้อมูลตามเวลาจริงของการสังเกตตัวอย่าง
ใช้ปลายทาง list กับพารามิเตอร์ filter เพื่อกรองข้อมูลตามเวลาจริงของการสังเกตตัวอย่าง
ตัวอย่าง
ส่งคำขอ
GET https://health.googleapis.com/v4/users/me/dataTypes/body-fat/dataPoints?filter=body_fat.sample_time.physical_time >= "2026-03-01T00:00:00Z" Authorization: Bearer access-token Accept: application/json
คำตอบ
{
"dataPoints": [
{
"name": "users/2515055256096816351/dataTypes/body-fat/dataPoints/1234567890",
"dataSource": {
"recordingMethod": "UNKNOWN",
"application": {
"packageName": "",
"webClientId": "",
"googleWebClientId": "google-web-client-id"
},
"platform": "GOOGLE_WEB_API"
},
"-->bodyFat<--": {
"sampleTime": {
"physicalTime": "2026-03-10T10:00:00Z",
"utcOffset": "0s",
"civilTime": {
"date": {
"year": 2026,
"month": 3,
"day": 10
},
"time": {
"hours": 10
}
}
},
"percentage": 20
}
}
"nextPageToken": ""
}กรองข้อมูลตามแหล่งข้อมูล เช่น อุปกรณ์สวมใส่
ใช้ reconcile
ปลายทาง เพื่อรับ
ข้อมูลสำหรับ "ตระกูลแหล่งข้อมูล" ที่เฉพาะเจาะจง โดยระบุพารามิเตอร์ dataSourceFamily เป็นพารามิเตอร์การค้นหา
ตารางต่อไปนี้อธิบายตัวเลือก dataSourceFamily ที่รองรับ
| ตัวเลือก | คำอธิบาย |
|---|---|
users/me/dataSourceFamilies/all-sources |
ค่าเริ่มต้น รวมข้อมูลจากแหล่งข้อมูลทั้งหมดที่เข้าถึงได้ |
users/me/dataSourceFamilies/google-wearables |
รวมข้อมูลจากอุปกรณ์ติดตามของ Google และ Fitbit (เช่น อุปกรณ์ติดตาม Fitbit และ Pixel Watch) ไม่รวมข้อมูลที่บันทึกด้วยตนเอง |
users/me/dataSourceFamilies/google-sources |
รวมข้อมูลใน Google จากบุคคลที่หนึ่ง เช่น ข้อมูลจากอุปกรณ์ติดตามและข้อมูลที่บันทึกด้วยตนเอง |
ตัวอย่างการกรองเฉพาะการนอนหลับที่บันทึกโดยอุปกรณ์ติดตามสำหรับวันหลังจาก 2026-03-03
ส่งคำขอ
GET https://health.googleapis.com/v4/users/me/dataTypes/sleep/dataPoints:reconcile?dataSourceFamily=users/me/dataSourceFamilies/google-wearables&filter=sleep.interval.civil_end_time >= "2026-03-03" Authorization: Bearer access-token Accept: application/json
คำตอบ
{
"dataPoints": [
{
"name": "users/2515055256096816351/dataTypes/sleep/dataPoints/2724123844716220216",
"dataSource": {
"recordingMethod": "DERIVED",
"device": {
"displayName": "Charge 6"
},
"platform": "FITBIT"
},
"sleep": {
"interval": {
"startTime": "2026-03-03T20:57:30Z",
"startUtcOffset": "0s",
"endTime": "2026-03-04T04:41:30Z",
"endUtcOffset": "0s"
},
"type": "STAGES",
"stages": [
{
"startTime": "2026-03-03T20:57:30Z",
"startUtcOffset": "0s",
"endTime": "2026-03-03T20:59:30Z",
"endUtcOffset": "0s",
"type": "AWAKE",
"createTime": "2026-03-04T04:43:40.937183Z",
"updateTime": "2026-03-04T04:43:40.937183Z"
},
…
{
"startTime": "2026-03-04T04:07:30Z",
"startUtcOffset": "0s",
"endTime": "2026-03-04T04:41:30Z",
"endUtcOffset": "0s",
"type": "AWAKE",
"createTime": "2026-03-04T04:43:40.937183Z",
"updateTime": "2026-03-04T04:43:40.937183Z"
}
],
"metadata": {
"stagesStatus": "SUCCEEDED",
"processed": true,
"main": true
},
"summary": {
"minutesInSleepPeriod": "464",
"minutesAfterWakeUp": "0",
"minutesToFallAsleep": "0",
"minutesAsleep": "407",
"minutesAwake": "57",
"stagesSummary": [
{
"type": "AWAKE",
"minutes": "56",
"count": "12"
},
{
"type": "LIGHT",
"minutes": "198",
"count": "19"
},
{
"type": "DEEP",
"minutes": "114",
"count": "10"
},
{
"type": "REM",
"minutes": "94",
"count": "4"
}
]
},
"createTime": "2026-03-04T04:43:40.337983Z",
"updateTime": "2026-03-04T04:43:40.937183Z"
}
}
],
"nextPageToken": ""
}รวมจุดข้อมูลในช่วงเวลาหนึ่ง
ใช้ rollUp
ปลายทาง เพื่อแสดงผลรวมของจุดข้อมูลตามหน้าต่างเป็นวินาทีในช่วง datetime ตามเวลาจริงของผู้ใช้ (ใน UTC)
เมื่อเรียกปลายทาง rollUp คุณต้องระบุเนื้อความของคำขอที่แสดงช่วงวันที่ที่ต้องการในเวลาจริงของผู้ใช้ ตัวอย่าง
ส่งคำขอ
POST https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints:rollUp
Authorization: Bearer access-token
Accept: application/json
{
"range": {
"startTime": "2026-02-17T17:00:00Z",
"endTime": "2026-02-17T17:59:59Z"
},
"windowSize": "30s"
}คำตอบ
{
"rollupDataPoints": [
{
"startTime": "2026-02-17T17:55:00Z",
"endTime": "2026-02-17T17:55:30Z",
"steps": {
"countSum": "41"
}
},
{
"startTime": "2026-02-17T17:54:00Z",
"endTime": "2026-02-17T17:54:30Z",
"steps": {
"countSum": "31"
}
},
...
]
}รวมข้อมูลตลอดทั้งวันหรือหลายวัน
ควรใช้ dailyRollUp
ปลายทาง เมื่อต้องการรวมข้อมูลตลอดทั้ง
วันหรือหลายวัน ซึ่งเรียกว่า windowSize ระบุช่วงเวลาจริงแบบปิด-เปิดสำหรับช่วงเวลาที่ต้องการในเนื้อความของคำขอ คุณจะได้รับผลรวมหรือค่าเฉลี่ยในช่วงเวลาดังกล่าว ทั้งนี้ขึ้นอยู่กับประเภทข้อมูล
ตัวอย่าง
ส่งคำขอ
POST https://health.googleapis.com/v4/users/me/dataTypes/steps/dataPoints:dailyRollUp
Authorization: Bearer access-token
Accept: application/json
{
"range": {
"start": {
"date": {
"year": 2026,
"month": 2,
"day": 26
},
"time": {
"hours": 0,
"minutes": 0,
"seconds": 0,
"nanos": 0
}
},
"end": {
"date": {
"year": 2026,
"month": 2,
"day": 26
},
"time": {
"hours": 23,
"minutes": 59,
"seconds": 59,
"nanos": 0
}
}
},
"windowSizeDays": 1
}คำตอบ
{
"rollupDataPoints": [
{
"civilStartTime": {
"date": {
"year": 2026,
"month": 2,
"day": 26
},
"time": {}
},
"civilEndTime": {
"date": {
"year": 2026,
"month": 2,
"day": 26
},
"time": {
"hours": 23,
"minutes": 59,
"seconds": 59
}
},
"steps": {
"countSum": "3822"
}
}
]
}แทรกหรืออัปเดตข้อมูลสุขภาพของผู้ใช้
ใช้ patch
ปลายทาง เพื่อแทรกหรือ
อัปเดตข้อมูลแอป Fitbit ของผู้ใช้
ตัวอย่างที่ผู้ใช้บันทึกไขมันร่างกายบนเครื่องชั่งที่เรียกว่า "HumanScale" จากบริษัท "Scales R Us" ค่าไขมันร่างกายใหม่ของผู้ใช้คือ 20% สำหรับวันที่ 2026-03-10
ส่งคำขอ
PATCH https://health.googleapis.com/v4/users/me/dataTypes/body-fat/dataPoints/1234567890
Authorization: Bearer access-token
content-length: 329
{
"name": "bodyFatName",
"dataSource": {
"recordingMethod": "ACTIVELY_MEASURED",
"device": {
"formFactor": "SCALE",
"manufacturer": "Scales R Us",
"displayName": "HumanScale"
}
},
"bodyFat": {
"sampleTime": {
"physicalTime": "2026-03-10T10:00:00Z"
},
"percentage": 20
}
}คำตอบ
{
"done": true,
"response": {
"@type": "type.googleapis.com/google.devicesandservices.health.v4main.DataPoint",
"name": "users/2515055256096816351/dataTypes/body-fat/dataPoints/1234567890",
"dataSource": {
"recordingMethod": "ACTIVELY_MEASURED",
"device": {
"formFactor": "SCALE",
"manufacturer": "Scales R Us",
"displayName": "HumanScale"
},
"application": {
"googleWebClientId": "618308034039.apps.googleusercontent.com"
},
"platform": "GOOGLE_WEB_API"
},
"bodyFat": {
"sampleTime": {
"physicalTime": "2026-03-10T10:00:00Z"
},
"percentage": 20
}
}
}บันทึกรายการอาหาร
หากต้องการบันทึกรายการอาหาร ให้ส่งคำขอ POST ไปยังปลายทาง dataPoints ของ nutrition-log เนื้อความของคำขอจะมี DataPoint ที่มีออบเจ็กต์ nutritionLog
ดูข้อมูลเพิ่มเติมได้ที่คู่มือโภชนาการ
ตัวอย่าง
ส่งคำขอ
POST https://health.googleapis.com/v4/users/me/dataTypes/nutrition-log/dataPoints
Authorization: Bearer access-token
Content-Type: application/json
{
"nutritionLog": {
"interval": {
"startTime": "2026-06-16T12:00:00Z",
"endTime": "2026-06-16T12:30:00Z"
},
"foodDisplayName": "Banana",
"mealType": "LUNCH",
"energy": {
"kcal": 105
},
"totalCarbohydrate": {
"grams": 27
},
"totalFat": {
"grams": 0.3
}
}
}คำตอบ
{
"done": true,
"response": {
"@type": "type.googleapis.com/google.devicesandservices.health.v4.DataPoint",
"name": "users/2515055256096816351/dataTypes/nutrition-log/dataPoints/567890",
"dataSource": {
"recordingMethod": "ACTIVELY_MEASURED",
"platform": "GOOGLE_WEB_API"
},
"nutritionLog": {
"interval": {
"startTime": "2026-06-16T12:00:00Z",
"startUtcOffset": "0s",
"endTime": "2026-06-16T12:30:00Z",
"endUtcOffset": "0s"
},
"energy": {
"kcal": 105
},
"totalCarbohydrate": {
"grams": 27
},
"totalFat": {
"grams": 0.3
},
"mealType": "LUNCH",
"foodDisplayName": "Banana"
}
}
}ลบข้อมูลสุขภาพของผู้ใช้
ใช้ batchDelete
เมธอด เพื่อลบ
อาร์เรย์ของข้อมูลแอป Fitbit ของผู้ใช้
ตัวอย่างที่ผู้ใช้เคยบันทึกไขมันร่างกายบนเครื่องชั่ง แต่ต้องการลบบันทึก โดยใช้ user-id และ data-point-id จากการดำเนินการแทรกเดิม
ส่งคำขอ
POST https://health.googleapis.com/v4/users/me/dataTypes/body-fat/dataPoints:batchDelete
Authorization: Bearer access-token
Accept: application/json
content-length: 93
{
"names": [
"users/2515055256096816351/dataTypes/body-fat/dataPoints/1234567890"
]
}คำตอบ
{
"done": true,
"response": {
"@type": "type.googleapis.com/google.devicesandservices.health.v4main.BatchDeleteDataPointsResponse"
}
}ค้นหาข้อมูลอุปกรณ์
ใช้ปลายทาง list เพื่อ
ดึงข้อมูลรายการอุปกรณ์ที่จับคู่กับบัญชีของผู้ใช้ ซึ่งรวมถึงข้อมูลรุ่นของอุปกรณ์ (deviceVersion) และเวลาล่าสุดที่ซิงค์กับแอป Google Health บนอุปกรณ์เคลื่อนที่ (lastSyncTime)
การกำหนดค่ารายการและข้อมูลการซิงค์มีประโยชน์สำหรับการแก้ปัญหาการซิงค์หรือการดึงข้อมูลย้อนหลังนับตั้งแต่เวลาซิงค์ล่าสุด
ตัวอย่าง
ส่งคำขอ
GET https://health.googleapis.com/v4/users/me/pairedDevices Authorization: Bearer access-token Accept: application/json
คำตอบ
{
"pairedDevices": [
{
"name": "users/me/pairedDevices/123456",
"deviceType": "TRACKER",
"batteryStatus": "High",
"batteryLevel": 88,
"lastSyncTime": "2026-03-04T07:05:00Z",
"deviceVersion": "Charge 6",
"macAddress": "00:11:22:33:44:55",
"features": [
"STEPS",
"HEART_RATE"
]
}
]
}ค้นหาข้อมูลย้อนหลัง
ข้อดีหลักอย่างหนึ่งของ Google Health API คือความสามารถในการติดตามประสิทธิภาพของผู้ใช้และตรวจสอบสัญญาณชีพของผู้ใช้ในช่วงระยะเวลานาน คุณสามารถค้นหาข้อมูลของผู้ใช้ได้นานเท่าที่ข้อมูลนั้นได้รับการบันทึกไว้ โดย API จะไม่กำหนดข้อจำกัดเกี่ยวกับปริมาณข้อมูลย้อนหลังที่แอปพลิเคชันของคุณใช้ได้
อย่างไรก็ตาม การค้นหาข้อมูลย้อนหลังยังคงอยู่ภายใต้ขีดจำกัดอัตรามาตรฐาน rate limits Google Health API ใช้การแบ่งหน้าอัตโนมัติที่มีขนาดหน้าเฉพาะปลายทางเพื่อจัดการความเสถียรของระบบและป้องกันเพย์โหลดที่มากเกินไป โปรดทราบขอบเขตและลักษณะการทำงานต่อไปนี้
- การแบ่งหน้าอัตโนมัติ: หากคุณค้นหาข้อมูลในช่วงเวลานาน API จะแสดงเฉพาะหน้าแรกของผลลัพธ์ไม่เกินขีดจำกัดขนาดหน้าสำหรับปลายทางนั้น พร้อมกับ
nextPageTokenคุณต้องใช้nextPageTokenเพื่อขอหน้าถัดไป - ขนาดหน้าแบบแปรผัน: ขีดจำกัดสูงสุดจะขึ้นอยู่กับปลายทาง
และประเภทข้อมูล สำหรับประเภทข้อมูลส่วนใหญ่ ขนาดหน้าจะจำกัดไว้ที่ 10,000 รายการ
อย่างไรก็ตาม สำหรับประเภทข้อมูลบางอย่าง เช่น
exerciseและsleep, ขนาดหน้าเริ่มต้นและขนาดหน้าสูงสุดจะจำกัดไว้ที่ 25 รายการ ตัวอย่างเช่น หากไคลเอ็นต์ขอ ข้อมูลการนอนหลับทั้งหมดในช่วง 10 ปีที่ผ่านมา API จะยังคงแสดงเซสชันการนอนหลับเพียง 25 รายการ ในหน้าแรก - ข้อจำกัดช่วงวันที่ของการรวมข้อมูล: สำหรับปลายทางการรวมข้อมูลและการรวมข้อมูล
(เช่น
rollUpและdailyRollUp) ช่วงวันที่ของการค้นหาจะถูกจำกัด ตามประเภทข้อมูล ดังนี้:- ช่วงสูงสุด 14 วันสำหรับ
calories-in-heart-rate-zone,heart-rate,active-minutesและtotal-calories - ช่วงสูงสุด 90 วันสำหรับประเภทข้อมูลการรวมข้อมูลอื่นๆ ทั้งหมด
- ช่วงสูงสุด 14 วันสำหรับ
การดึงข้อมูลทั้งชุดข้อมูลจะต้องมีการแบ่งหน้าตามลำดับ ทั้งนี้ขึ้นอยู่กับปริมาณข้อมูลย้อนหลังที่แอปพลิเคชันของคุณต้องการ โปรดคำนึงถึงเรื่องนี้เมื่อออกแบบกระบวนการซิงค์ข้อมูลของแอปพลิเคชัน
ทำตามหลักเกณฑ์ต่อไปนี้เมื่อค้นหาข้อมูลย้อนหลังเพื่อให้ได้ประสิทธิภาพสูงสุดและหลีกเลี่ยงข้อผิดพลาดของ API
การซิงค์ข้อมูลแบบแบ่งระยะ (การโหลดแบบร้อนเทียบกับการโหลดแบบเย็น)
- การโหลดแบบ "ร้อน" ครั้งแรก: ดึงและแสดงข้อมูลเฉพาะ 7-14 วันล่าสุดในระหว่างลำดับการโหลดหลัก วิธีนี้ ช่วยให้ผู้ใช้เห็นข้อมูลได้ทันทีโดยไม่ต้องรอการค้นหาที่ใช้เวลานาน
- การโหลดแบบ "เย็น" ในเบื้องหลัง: มอบหมายการดึงข้อมูลย้อนหลังที่เก่ากว่า ไปยังคิวแบบอะซิงโครนัสที่มีลำดับความสำคัญต่ำกว่าหรือกระบวนการเบื้องหลัง หลังจากแสดง UI หลักแล้ว
การแบ่งส่วนการค้นหาสำหรับการรวมข้อมูล
- เนื่องจากปลายทางการรวมข้อมูลและการรวมข้อมูลรายวันบังคับใช้ขีดจำกัดช่วงวันที่สูงสุด (14 หรือ 90 วัน ขึ้นอยู่กับประเภทข้อมูล) คุณจึงต้องแบ่งการค้นหาการรวมข้อมูลย้อนหลังขนาดใหญ่ออกเป็นช่วงเวลาที่เล็กลงตามลำดับ ภายในขีดจำกัดเหล่านี้
- จัดกลุ่มหรือจัดลำดับการค้นหาย่อยเหล่านี้อย่างปลอดภัยเพื่อปฏิบัติตามขีดจำกัดการทำงานพร้อมกัน และรักษาตัวบ่งชี้ความคืบหน้าของ UI ให้คงที่
ใช้ประโยชน์จากการรวมข้อมูลที่รวมไว้ล่วงหน้า
ปรับโครงสร้างแดชบอร์ดภาพรวมและแผนภูมิแนวโน้มเพื่อใช้ปลายทางสรุปที่รวมไว้ล่วงหน้า (เช่น DailyRollUpDataPoints) ซึ่งจะช่วยลดค่าใช้จ่ายในการประมวลผลในแบ็กเอนด์และเวลาในการโอนข้อมูลไปยังไคลเอ็นต์ลงอย่างมาก
การจัดการข้อผิดพลาดที่ยืดหยุ่น (การลองใหม่แบบอัจฉริยะ)
- ใช้การจัดการ Exponential Backoff ที่เข้มงวดเมื่อพบการจำกัดอัตราคำขอ (
429 Too Many Requests) และการหมดเวลาของเกตเวย์เซิร์ฟเวอร์ (504 Gateway Timeout) อย่าลองเพย์โหลดขนาดใหญ่ที่ล้มเหลวใหม่ทันที การลองใหม่ทันทีจะเพิ่มความหนาแน่นของแบ็กเอนด์และทำให้ ระบบเสื่อมประสิทธิภาพ