इस पेज पर, REST API के कन्वेंशनल तरीकों की खास जानकारी दी गई है. साथ ही, इसमें Google Health API की आम तौर पर की जाने वाली कार्रवाइयों और हर कार्रवाई के उदाहरणों की इंडेक्स भी दी गई है.
REST API के कन्वेंशनल तरीके
Google Health API, Google API Improvement Proposals (AIP) के स्टैंडर्ड के मुताबिक काम करता है. खास तौर पर, AIP-127 (एचटीटीपी और gRPC ट्रांसकोडिंग) और AIP-131 से लेकर AIP-135 (स्टैंडर्ड तरीके) के मुताबिक. इन स्टैंडर्ड से यह तय होता है कि प्रोटो मैसेज से एचटीटीपी अनुरोध में डेटा को कैसे मैप किया जाता है.
क्वेरी पैरामीटर
क्वेरी पैरामीटर का इस्तेमाल तब किया जाता है, जब डेटा यूआरएल का हिस्सा होता है. इसका इस्तेमाल मुख्य तौर पर GET अनुरोधों (किसी संसाधन को फ़ेच करना) या LIST अनुरोधों (फ़िल्टर करना/पेज पर बांटना) के लिए किया जाता है. हालांकि, इसका इस्तेमाल DELETE कार्रवाइयों के लिए भी किया जाता है.
- प्लेसमेंट: इसे
?के बाद यूआरएल में जोड़ा जाता है. - सिंटैक्स: यह कुंजी-वैल्यू के जोड़े के तौर पर होता है, जो
&से अलग किए गए हैं. - मैपिंग: अनुरोध के मैसेज में मौजूद हर फ़ील्ड को क्वेरी पैरामीटर पर मैप किया जाता है. हालांकि, यूआरएल पाथ टेंप्लेट में मौजूद फ़ील्ड को मैप नहीं किया जाता.
- इनके लिए सबसे सही: सामान्य टाइप (स्ट्रिंग, इंट, एनम) और बार-बार इस्तेमाल होने वाले फ़ील्ड.
सिंटैक्स का उदाहरण:
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"
अनुरोध का मुख्य भाग
अनुरोध के मुख्य भाग का इस्तेमाल तब किया जाता है, जब डेटा किसी संसाधन की स्थिति में बदलाव करता है या यूआरएल के लिए बहुत बड़ा होता है. मुख्य भाग आम तौर पर, संसाधन का JSON फ़ॉर्मैट होता है. इसका इस्तेमाल आम तौर पर POST, PATCH, और PUT कार्रवाइयों के लिए किया जाता है.
- प्लेसमेंट: यह एचटीटीपी पेलोड में होता है. यह यूआरएल में नहीं दिखता.
- सिंटैक्स: इसे JSON ऑब्जेक्ट के तौर पर फ़ॉर्मैट किया जाता है.
- मैपिंग: इसे
google.api.httpएनोटेशन में तय किया जाता है.body: "*"का मतलब है कि पूरा मैसेज, मुख्य भाग है.body: "resource_name"का मतलब है कि प्रोटो में सिर्फ़ एक खास फ़ील्ड, मुख्य भाग है.
- इनके लिए सबसे सही: जटिल ऑब्जेक्ट, नेस्ट किए गए मैसेज, और संवेदनशील डेटा.
सिंटैक्स का उदाहरण:
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"
}हाइब्रिड केस
AIP-134 के मुताबिक Update तरीके या PATCH कार्रवाई में, दोनों का इस्तेमाल किया जाता है.
यूआरएल में संसाधन का नाम होता है, मुख्य भाग में अपडेट किया गया संसाधन डेटा होता है, और क्वेरी पैरामीटर (आम तौर पर 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 के निर्देश | इसका इस्तेमाल, खोजने, फ़िल्टर करने, और पढ़ने की कार्रवाइयों के लिए किया जाता है. | इसका इस्तेमाल, लिखने की कार्रवाइयों के लिए किया जाता है. |
| वीडियो किसको दिखे | यह ब्राउज़र के इतिहास और सर्वर लॉग में दिखता है. | यह यूआरएल में नहीं दिखता. |
| जटिलता | यह फ़्लैट या बार-बार इस्तेमाल होने वाले स्ट्रक्चर तक सीमित है. | यह डीपली नेस्ट किए गए JSON ऑब्जेक्ट के साथ काम करता है. |
| एन्कोडिंग | इसे यूआरएल-एन्कोड किया जाना चाहिए. उदाहरण के लिए, स्पेस %20 बन जाते हैं. |
स्टैंडर्ड JSON एन्कोडिंग. |
तारीख
Google Health API में सभी तारीखें, YYYY-MM-DD फ़ॉर्मैट में दिखती हैं. Nutrition API, तारीख की वैल्यू के लिए आईएसओ-8601 स्टैंडर्ड के साथ काम करता है. हालांकि, इसके लिए ये शर्तें लागू होती हैं:
- साल के लिए चार अंकों वाला फ़ॉर्मैट
YYYY - साल की वैल्यू 0000-9999 के बीच होनी चाहिए
- आईएसओ-8601 स्टैंडर्ड या अन्य ईपॉक के तहत, शुरू होने की तारीख से जुड़ी पाबंदियां लागू नहीं की जाती हैं
हेडर
Google Health API के एंडपॉइंट को एक्ज़ीक्यूट करने के लिए, सही हेडर और ऐक्सेस टोकन का इस्तेमाल करना ज़रूरी है. GET और POST, दोनों तरह के अनुरोधों के लिए, इस हेडर का इस्तेमाल करने का सुझाव दिया जाता है:
Authorization: Bearer access-token Accept: application/json
एपीआई की कार्रवाइयों की इंडेक्स
इस सेक्शन में, Google Health API की आम तौर पर की जाने वाली कार्रवाइयों और हर कार्रवाई के उदाहरणों की इंडेक्स दी गई है.
Fitbit या Google के उपयोगकर्ता का आईडी पाना
Google OAuth 2.0 के ज़रिए, उपयोगकर्ता की सहमति मिलने के बाद, टोकन के जवाब में Fitbit या Google के उपयोगकर्ता का आईडी नहीं होता. उपयोगकर्ता का आईडी पाने के लिए, getIdentity एंडपॉइंट पर कॉल करें. getIdentity
, Fitbit के पुराने उपयोगकर्ता का आईडी और Google के उपयोगकर्ता का आईडी, दोनों दिखाता है.
हमारा सुझाव है कि OAuth के ज़रिए, नए उपयोगकर्ता की सहमति मिलते ही, getIdentity एंडपॉइंट पर कॉल करें और दोनों उपयोगकर्ता आईडी सेव करें. इससे, आपके इंटिग्रेशन में बैकवर्ड और फ़ॉरवर्ड कंपैटिबिलिटी मिलती है.
उदाहरण के लिए:
अनुरोध
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 सीमा
के आधार पर तय होता है.
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"
}
}
]
}उपयोगकर्ता का सेहत का डेटा जोड़ना या अपडेट करना
उपयोगकर्ता के Fitbit ऐप्लिकेशन का डेटा जोड़ने या
अपडेट करने के लिए, patch
एंडपॉइंट का इस्तेमाल करें.
यहां एक उदाहरण दिया गया है, जिसमें किसी उपयोगकर्ता ने "Scales R Us" कंपनी के "HumanScale" नाम के स्केल पर, अपने शरीर में मौजूद बॉडी फ़ैट का डेटा रिकॉर्ड किया है. 2026-03-10 की तारीख के लिए, उपयोगकर्ता के शरीर में मौजूद फ़ैट का नया डेटा 20% है.
अनुरोध
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
}
}
}खाने के किसी आइटम को लॉग करना
खाने के किसी आइटम को लॉग करने के लिए, nutrition-log dataPoints एंडपॉइंट पर POST अनुरोध भेजें. अनुरोध के मुख्य भाग में, nutritionLog ऑब्जेक्ट के साथ DataPoint होता है.
ज़्यादा जानकारी के लिए, न्यूट्रिशन गाइड देखें.
उदाहरण के लिए:
अनुरोध
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"
}
}
}उपयोगकर्ता का सेहत का डेटा मिटाना
उपयोगकर्ता के Fitbit ऐप्लिकेशन के डेटा की किसी कलेक्शन को मिटाने के लिए, batchDelete
तरीके का इस्तेमाल करें.
यहां एक उदाहरण दिया गया है, जिसमें किसी उपयोगकर्ता ने पहले स्केल पर अपने शरीर में मौजूद बॉडी फ़ैट का डेटा रिकॉर्ड किया था. हालांकि, अब वह उस रिकॉर्ड को मिटाना चाहता है. डेटा जोड़ने की मूल कार्रवाई से मिले 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 का एक मुख्य फ़ायदा यह है कि इससे उपयोगकर्ता की परफ़ॉर्मेंस को ट्रैक किया जा सकता है. साथ ही, लंबे समय तक उसके स्वास्थ्य से जुड़े अहम डेटा को मॉनिटर किया जा सकता है. उपयोगकर्ता के डेटा के लिए, तब तक क्वेरी की जा सकती है, जब तक उसे रिकॉर्ड किया गया है. एपीआई, आपके ऐप्लिकेशन के इस्तेमाल किए जा सकने वाले पुराने डेटा की मात्रा पर कोई पाबंदी या रोक नहीं लगाता.
हालांकि, पुराने डेटा के लिए क्वेरी करने पर, अब भी दर की स्टैंडर्ड सीमाएं लागू होती हैं. सिस्टम की स्थिरता को मैनेज करने और ज़्यादा पेलोड से बचने के लिए, Google Health API, एंडपॉइंट के हिसाब से तय किए गए पेज के साइज़ के साथ, पेज पर बांटने की सुविधा का इस्तेमाल करता है. इन सीमाओं और व्यवहार पर ध्यान दें:
- पेज पर बांटने की सुविधा: अगर डेटा की लंबी अवधि के लिए क्वेरी की जाती है, तो एपी101} आई, उस एंडपॉइंट के लिए तय किए गए पेज के साइज़ की सीमा तक, नतीजों का सिर्फ़ पहला पेज दिखाएगा. साथ ही,
nextPageTokenभी दिखाएगा. इसके बाद के पेजों का अनुरोध करने के लिए, आपकोnextPageTokenका इस्तेमाल करना होगा. - पेज के साइज़ की सीमाएं: सीमाएं, एंडपॉइंट
और डेटा टाइप के हिसाब से तय होती हैं. ज़्यादातर डेटा टाइप के लिए, पेज के साइज़ की सीमा ज़्यादा से ज़्यादा 10,000 होती है.
हालांकि,
exerciseऔरsleepजैसे कुछ डेटा टाइप के लिए, डिफ़ॉल्ट और ज़्यादा से ज़्यादा पेज के साइज़ की सीमा 25 होती है. उदाहरण के लिए, अगर कोई क्लाइंट पिछले 10 सालों के नींद के सभी डेटा का अनुरोध करता है तो एपीआई, पहले पेज पर नींद के सिर्फ़ 25 सेशन दिखाएगा. - डेटा रोलअप की तारीख की सीमाएं: डेटा रोलअप और एग्रीगेशन एंडपॉइंट
(जैसे,
rollUpऔरdailyRollUp) के लिए, क्वेरी की तारीख की सीमाएं, डेटा टाइप के हिसाब से तय होती हैं:calories-in-heart-rate-zone,heart-rate,active-minutes, औरtotal-caloriesके लिए, ज़्यादा से ज़्यादा 14 दिनों की सीमा.- रोलअप के अन्य सभी डेटा टाइप के लिए, ज़्यादा से ज़्यादा 90 दिनों की सीमा.
आपके ऐप्लिकेशन को पुराने डेटा की जितनी ज़रूरत है, पूरे डेटासेट को पाने के लिए, पेजों को क्रम से बांटना होगा. अपने ऐप्लिकेशन की डेटा सिंक करने की प्रोसेस डिज़ाइन करते समय, इस बात का ध्यान रखें.
पुराने डेटा के लिए क्वेरी करते समय, इन दिशा-निर्देशों का पालन करें, ताकि परफ़ॉर्मेंस बेहतर हो और एपीआई से जुड़ी गड़बड़ियां न हों:
फ़ेज़ के हिसाब से डेटा सिंक करना (हॉट वर्सेस कोल्ड लोड)
- शुरुआती "हॉट" लोड: प्राइमरी लोड सीक्वेंस के दौरान, सिर्फ़ पिछले 7 से 14 दिनों का सबसे नया डेटा फ़ेच करें और रेंडर करें. इससे यह पक्का होता है कि उपयोगकर्ताओं को डेटा तुरंत दिखे. उन्हें लंबे समय तक चलने वाली क्वेरी के लिए इंतज़ार न करना पड़े.
- बैकग्राउंड "कोल्ड" लोड: प्राइमरी यूज़र इंटरफ़ेस (यूआई) रेंडर होने के बाद, पुराने डेटा को एसिंक्रोनस, कम प्राथमिकता वाली क्यू या बैकग्राउंड प्रोसेस में डेलिगेट करें.
एग्रीगेशन के लिए क्वेरी चंकिंग
- रोलअप और डेली रोलअप एंडपॉइंट, तारीख की ज़्यादा से ज़्यादा सीमा लागू करते हैं (डेटा टाइप के हिसाब से 14 या 90 दिन). इसलिए, आपको पुराने डेटा के बड़े एग्रीगेशन क्वेरी को इन सीमाओं के अंदर, छोटे-छोटे, क्रम से तय किए गए इंटरवल में तोड़ना होगा.
- एक साथ कई कार्रवाइयां करने की सीमाओं का पालन करने और यूआई की प्रोग्रेस इंडिकेटर को बनाए रखने के लिए, इन सब-क्वेरी को सुरक्षित तरीके से बैच करें या क्रम से चलाएं.
पहले से एग्रीगेट किए गए रोल-अप का इस्तेमाल करना
खास जानकारी वाले डैशबोर्ड और ट्रेंड चार्ट को फिर से स्ट्रक्चर करें, ताकि पहले से एग्रीगेट किए गए, समरी एंडपॉइंट (जैसे, DailyRollUpDataPoints) का इस्तेमाल किया जा सके. इससे, बैकएंड पर कंप्यूटिंग का ओवरहेड और क्लाइंट को नेटवर्क ट्रांसफ़र का समय काफ़ी कम हो जाएगा.
गड़बड़ी ठीक करने की सुविधा (स्मार्ट रीट्राइज़)
- दर की सीमाएं (
429 Too Many Requests) और सर्वर गेटवे टाइमआउट (504 Gateway Timeout) होने पर, एक्स्पोनेंशियल बैकऑफ़ हैंडलिंग लागू करें. बड़े, फ़ेल हुए पेलोड को तुरंत फिर से भेजने की कोशिश न करें. तुरंत फिर से कोशिश करने से, बैकएंड पर कंजेशन बढ़ जाता है और सिस्टम की परफ़ॉर्मेंस खराब हो जाती है.