หน้านี้ให้ภาพรวมของข้อกำหนด 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 ไปยังปลายทางจุดข้อมูล 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 ที่เกี่ยวข้องกับขีดจำกัดเหล่านี้ โปรดทราบขอบเขตการแบ่งหน้าและคำขอต่อไปนี้
- แต่ละปลายทางจะแสดงผลขนาดหน้าสูงสุด 10,000 จุดข้อมูลต่อหน้า
- ช่วงวันที่ค้นหาจะจำกัดไว้ที่ 14 ถึง 90 วันต่อคำขอ
การดึงข้อมูลทั้งชุดอาจต้องใช้คำขอต่อเนื่องหลายรายการและใช้เวลาเพิ่มเติม ทั้งนี้ขึ้นอยู่กับปริมาณข้อมูลย้อนหลังที่แอปพลิเคชันของคุณต้องการ โปรดคำนึงถึงเรื่องนี้เมื่อออกแบบกระบวนการซิงโครไนซ์ข้อมูลของแอปพลิเคชัน
ทำตามหลักเกณฑ์ต่อไปนี้เมื่อค้นหาข้อมูลย้อนหลังเพื่อให้ได้ประสิทธิภาพสูงสุดและหลีกเลี่ยงข้อผิดพลาดของ API
การซิงค์ข้อมูลแบบเป็นระยะ (การโหลดแบบ Hot Load เทียบกับการโหลดแบบ Cold Load)
- การโหลดแบบ "Hot Load" ครั้งแรก: ดึงและแสดงข้อมูลเฉพาะ 7-14 วันล่าสุดในระหว่างลำดับการโหลดหลัก วิธีนี้ ช่วยให้ผู้ใช้เห็นข้อมูลได้ทันทีโดยไม่ต้องรอการค้นหาที่ใช้เวลานาน
- การโหลดแบบ "Cold Load" ในเบื้องหลัง: มอบหมายการดึงข้อมูลย้อนหลังที่เก่ากว่า ไปยังคิวแบบอะซิงโครนัสที่มีลำดับความสำคัญต่ำกว่าหรือกระบวนการเบื้องหลัง หลังจากแสดง UI หลักแล้ว
การแบ่งคำค้นหาตามเวลา
- อย่าขอช่วงเวลาหลายปีหรือหลายเดือนในการเรียก API ครั้งเดียว แบ่งคำค้นหาข้อมูลย้อนหลังขนาดใหญ่ออกเป็นช่วงเวลาที่เล็กลงและต่อเนื่องกัน (เช่น 1 สัปดาห์ต่อคำขอ)
- จัดกลุ่มหรือจัดลำดับคำค้นหาย่อยเหล่านี้อย่างปลอดภัยเพื่อปฏิบัติตามขีดจำกัดการทำงานพร้อมกัน และรักษาตัวบ่งชี้ความคืบหน้าของ UI ให้คงที่
ใช้ประโยชน์จากการรวมข้อมูลที่รวมไว้ล่วงหน้า
ปรับโครงสร้างแดชบอร์ดภาพรวมและแผนภูมิแนวโน้มเพื่อใช้ปลายทางสรุปที่รวมไว้ล่วงหน้า (เช่น DailyRollUpDataPoints) ซึ่งจะช่วยลดค่าใช้จ่ายในการประมวลผลในแบ็กเอนด์และเวลาในการโอนเครือข่ายไปยังไคลเอ็นต์ลงอย่างมาก
การจัดการข้อผิดพลาดที่ยืดหยุ่น (การลองใหม่แบบอัจฉริยะ)
- ใช้การจัดการ Exponential Backoff อย่างเข้มงวดเมื่อพบการจำกัดอัตราคำขอ (
429 Too Many Requests) และการหมดเวลาของเกตเวย์เซิร์ฟเวอร์ (504 Gateway Timeout) อย่าลองเพย์โหลดขนาดใหญ่ที่ล้มเหลวใหม่ทันที การลองใหม่ทันทีจะเพิ่มความหนาแน่นของแบ็กเอนด์และทำให้ ระบบเสื่อมประสิทธิภาพ - หากคำค้นหาหมดเวลาซ้ำๆ ให้กลับไปใช้หน้าต่างเวลาที่เล็กลงโดยอัตโนมัติ (เช่น ลดช่วงเวลา 1 สัปดาห์เป็น 3 วัน)