Google Health API में डेटा के साथ काम करने का मुख्य तरीका यह है कि क्लाउड में मौजूद Google Health API के डेटा स्टोर और आपके ऐप्लिकेशन या बैकएंड डेटा स्टोर के बीच डेटा सिंक किया जाए. हालांकि, यह साइकल कई बातों के आधार पर अलग-अलग हो सकता है:
- क्या Google Health API में डेटा लिखा जा रहा है? क्या आपको सिर्फ़ पढ़ना है? या दोनों का इस्तेमाल करना चाहिए?
- क्या आपका डेटास्टोर, ऐप्लिकेशन या डिवाइस पर लोकल है? या अपने क्लाउड में?
- क्या आपको उपयोगकर्ता के ऐप्लिकेशन और पहनने जाने वाले डिवाइस के बीच, Google Health API का डेटा सिंक करना है? डिवाइसों को कितनी बार सिंक किया जाता है?
- आपको किस तरह के डेटा के साथ काम करना है? क्या बुनियादी बातों को गिना जाता है? मेज़रमेंट की यूनिट क्या हैं? क्या अलग-अलग सैंपल रेट वाली सीरीज़ को एक साथ इस्तेमाल किया जा सकता है?
- क्या आपको ऐप्लिकेशन के बैकग्राउंड में होने पर डेटा पढ़ना है?
- क्या आपको अपने ऐप्लिकेशन को उपयोगकर्ता की अनुमतियां मिलने से पहले रिकॉर्ड किए गए पुराने डेटा का इस्तेमाल करना है?
यह सब कैसे काम करता है, यह समझने के लिए Google Health API के डेटा सिंक करने की लाइफ़साइकल देखें. इस लाइफ़साइकल के दो वर्शन होते हैं: स्टैंडर्ड (पढ़ने और लिखने की अनुमति) और सिर्फ़ पढ़ने की अनुमति.
स्टैंडर्ड सिंक की लाइफ़साइकल
Google Health API के साथ इंटिग्रेट करने का मतलब है कि किसी ऐप्लिकेशन या बैकएंड डेटास्टोर में डेटा कॉपी करना. इस दस्तावेज़ में इस्तेमाल करने में आसानी हो, इसलिए हम इस डेटास्टोर को डेवलपर डेटास्टोर कहेंगे.
यहां "कॉपी करें" का मतलब किसी भी अलग गतिविधि से हो सकता है. जैसे, Google Health API से डेटा पढ़ना (डेवलपर के डेटास्टोर में कॉपी करना) या Google Health API में डेटा लिखना (Google Health API में कॉपी करना). इन कार्रवाइयों को किसी खास क्रम में बार-बार करना, सिंक करने का लाइफ़साइकल होता है.
पहली इमेज में, स्टैंडर्ड सिंक लाइफ़साइकल दिखाया गया है. इसमें, पहले बताए गए किसी भी फ़ैक्टर पर ध्यान दिए बिना, पढ़ने और लिखने की कार्रवाइयां शामिल होती हैं.
लिखें
- डेटा लिखने के लिए नया डेटा तैयार करना — किसी बाहरी डिवाइस या ऐप्लिकेशन से डेटा ट्रांसफ़र करें. साथ ही, डेटा पॉइंट को Google Health API के डेटा टाइप के साथ काम करने वाले JSON फ़ॉर्मैट में बदलें. ध्यान दें कि फ़िलहाल, Health API में लिखने के लिए, क्लाइंट की ओर से असाइन किए गए कस्टम आईडी इस्तेमाल नहीं किए जा सकते. इस तरह के आईडी,
POSTमें दिए जा सकते हैं, लेकिन इन्हें अनदेखा कर दिया जाता है. - अपसर्ट रिकॉर्ड — REST एंडपॉइंट का इस्तेमाल करके, Google Health API को डेटा पॉइंट सबमिट करें. रिकॉर्ड बनाने के लिए
POSTका इस्तेमाल करें. साथ ही, मौजूदा रिकॉर्ड डालने और अपडेट करने के लिएPATCHका इस्तेमाल करें.PATCHऑपरेशन के लिए ज़रूरी आईडी, पिछलेPOSTऑपरेशन (पिछले साइकल का अगला चरण) से मिलेंगे. - सर्वर से मिले संसाधन आईडी प्रोसेस करना — सर्वर से जनरेट किए गए आईडी का इस्तेमाल करते समय, सर्वर से मिले संसाधन
nameया आईडी को अपने डेवलपर डेटास्टोर में सेव करें. इससे आने वाले समय में अपडेट (PATCH) या मिटाने (DELETE) की सुविधा चालू की जा सकेगी. दोनों तरह के आईडी के बारे में ज़्यादा जानने के लिए, पहचान करने की रणनीतियां देखें.
पढ़ें
- रिकॉर्ड पढ़ना — REST एंडपॉइंट (
GETके साथfilterक्वेरी पैरामीटर औरpageTokenपेज नंबर डालना याrollUpऔरdailyRollUpजैसे एग्रीगेशन एंडपॉइंट) का इस्तेमाल करके, Google Health API से नया डेटा फ़ेच करें और मौजूदा डेटा में हुए बदलावों को फ़ेच करें. इसके अलावा, Webhook सदस्यताएं (projects.subscribers) का इस्तेमाल करके, रीयल-टाइम सूचनाएं पाएं. सूचना से सिर्फ़ यह पता चलता है कि नया डेटा उपलब्ध है. इससे यह पता नहीं चलता कि असल डेटा क्या है. - डेवलपर के डेटास्टोर का मिलान करें — नए और अपडेट किए गए डेटा का मिलान, डेवलपर के डेटास्टोर से करें. सिंक करने के दौरान, कनेक्ट किए गए डिवाइसों से एक जैसे इंटरवल मिल सकते हैं. Google Health API इन समस्याओं को कैसे हल करता है, यह जानने के लिए इंटरवल के टाइमस्टैंप और कनेक्ट किए गए डिवाइस को सिंक करना लेख पढ़ें.
इसके बाद, यह साइकल बाहरी डिवाइसों या ऐप्लिकेशन की ज़रूरतों के हिसाब से, तय समय पर दोहराई जाती है. आम तौर पर, हम आपके डेटास्टोर और Google Health API के बीच डेटा सिंक करने के लिए, इस क्रम का सुझाव देते हैं.
पहचान करने की रणनीतियां
अगर आपको Google Health API में डेटा सेव करना है, तो Google Health API के साथ इंटिग्रेशन बनाने से पहले, आपको डेटा पॉइंट (डेटा की बुनियादी इकाई) बनाते समय, संसाधन की पहचान करने की रणनीति चुननी होगी.
फ़िलहाल, Health API में लिखने के लिए, क्लाइंट के असाइन किए गए आईडी इस्तेमाल नहीं किए जा सकते.
इस तरह के आईडी, POST में दिए जा सकते हैं. हालांकि, इन्हें अनदेखा कर दिया जाता है. इस विकल्प के बारे में जानकारी देने के लिए, यहां ब्यौरा दिया गया है.
- सर्वर से जनरेट किए गए आईडी (डिफ़ॉल्ट विकल्प): क्लाइंट, आईडी के बिना डेटा सबमिट करता है. इसके बाद, Google Health API का बैकएंड, यूनीक सिस्टम आइडेंटिफ़ायर जनरेट करता है और उसे वापस भेजता है.
- क्लाइंट की ओर से असाइन किए गए कस्टम आईडी (AIP-133 के हिसाब से, अभी उपलब्ध नहीं है): क्लाइंट ऐप्लिकेशन, एक यूनीक आइडेंटिफ़ायर जनरेट करता है. उदाहरण के लिए, यूयूआईडी या लोकल डेटाबेस प्राइमरी कुंजी. इसके बाद, इसे संसाधन पाथ में उपलब्ध कराता है.
यहां दी गई टेबल में, दोनों आइडेंटिफ़िकेशन रणनीतियों की तुलना की गई है. इससे आपको अपने इंटिग्रेशन के लिए सही तरीका चुनने में मदद मिलेगी:
| सुविधा | सर्वर से जनरेट किए गए आईडी | क्लाइंट की ओर से असाइन किए गए कस्टम आईडी |
|---|---|---|
| आईडी जनरेट करना | सर्वर, POST
एक्ज़ीक्यूशन के दौरान रैंडम सिस्टम आईडी जनरेट करता है. |
क्लाइंट, राइट ऑपरेशन से पहले स्थानीय तौर पर स्टेबल आईडी जनरेट करता है (UUID v4 / इंटरनल पीके). |
| संसाधन पाथ | .../dataPoints/{server_id} (जवाब में मिला) |
.../dataPoints/{custom_id} |
| Post-Write Local Step | ज़रूरी है. आने वाले समय में अपडेट/मिटाने की सुविधा चालू करने के लिए, लौटाए गए server_id को लोकल डीबी में सेव करना ज़रूरी है. |
कोई नहीं. ऐप्लिकेशन के पास पहले से ही आईडी है. |
| आईडी मैपिंग टेबल | ज़रूरी है. क्लाइंट को दोनों तरह की मैपिंग (local_id ↔ server_id) बनाए रखनी होगी. |
ज़रूरी नहीं है. क्लाइंट अपनी प्राइमरी कुंजी का इस्तेमाल सीधे तौर पर करता है. |
| फिर से कोशिश करने का तरीका (कमज़ोर नेटवर्क) | डुप्लीकेट होने का जोखिम. टाइम आउट हो चुके POST को फिर से आज़माने पर, सर्वर के नए आईडी के साथ डुप्लीकेट रिकॉर्ड बन जाता है. |
सुरक्षित और आइडेमपोटेंट. एक ही custom_id के साथ POST को फिर से आज़माने पर, डुप्लीकेट नहीं बनता (409
ALREADY_EXISTS दिखाता है). |
| ऑफ़लाइन सिंक करने की सुविधा | सीमित है. इनका रेफ़रंस देने से पहले, सर्वर के जवाब का इंतज़ार करना होगा, ताकि आधिकारिक संसाधन आईडी मिल सकें. | पूरी. ऑफ़लाइन होने पर भी, स्टेबल आईडी का इस्तेमाल करके इकाइयां बनाई जा सकती हैं और उनमें बदलाव किया जा सकता है. इसके बाद, इंटरनेट से कनेक्ट होने पर उन्हें आसानी से सिंक किया जा सकता है. |
| फ़ॉर्मैट से जुड़ी पाबंदियां | इसे पूरी तरह से सर्वर मैनेज करता है. | इसमें ^[a-z0-9-]{4,63}$ (4–63 छोटे अक्षर, अंक, और हाइफ़न) होने चाहिए. |
| इसे कब चुनें |
अगर आपको ये काम करने हैं, तो सर्वर से जनरेट किए गए आईडी चुनें:
|
कस्टम आईडी तब चुनें, जब:
|
रीड-ओनली सिंक का लाइफ़साइकल
अगर कोई ऐप्लिकेशन सिर्फ़ Google Health API से डेटा पढ़ना चाहता है, तो उसे डेटा को अपने डेवलपर डेटास्टोर में कॉपी करना होगा. साथ ही, उसे लाइफ़साइकल के रिकॉन्सिलिएशन वाले हिस्से को मैनेज करना होगा.
पढ़ें सेक्शन में शामिल टास्क यहां भी लागू होते हैं.
दूसरी इमेज में, सिर्फ़ पढ़ने के लिए उपलब्ध लाइफ़साइकल के बारे में बताया गया है.
इंटरवल टाइमस्टैंप और कनेक्ट किए गए डिवाइसों के बीच डेटा सिंक होना
इंटरवल डेटा, किसी समयावधि में इकट्ठा किए गए मेज़रमेंट को दिखाता है. जैसे, कदमों की संख्या, धड़कन की दर या कसरत के सेशन. इसके उलट, किसी समय पर लिए गए मेज़रमेंट में, मैन्युअल तरीके से की गई एंट्री शामिल होती हैं. जैसे, फ़ूड लॉग या स्केल रीडिंग. इंटरवल डेटा आम तौर पर, कनेक्ट किए गए डिवाइसों को सिंक करने से मिलता है. जैसे, स्मार्टवॉच और फ़िटनेस ट्रैकर.
इंटरवल के टाइमस्टैंप (startTime और endTime) का इस्तेमाल करने पर, इंटरवल डेटा के साथ काम करने के दौरान कुछ खास व्यवहार देखने को मिलते हैं. इस सेक्शन में बताया गया है कि समयसीमाएं एक-दूसरे से क्यों ओवरलैप करती हैं. साथ ही, इसमें list और reconcile एंडपॉइंट की तुलना की गई है.
कनेक्ट किए गए डिवाइसों से मिले डेटा में एक ही समय के लिए कई बार डेटा मिलना
कनेक्ट किए गए डिवाइस, जैसे कि Fitbit ट्रैकर और Google Pixel Watch, पहनने के दौरान लगातार बायोमेट्रिक डेटा इकट्ठा करते हैं. कोई डिवाइस, Google Health के साथ डेटा पॉइंट सिंक करने के बाद, मौजूदा रिकॉर्ड में बदलाव नहीं करता है. उनके सेव किए गए इंटरवल के टाइमस्टैंप में कोई बदलाव नहीं होता.
हालांकि, बाद के सिंक साइकल से पहले, उपयोगकर्ता के डिवाइस पर मौजूद एल्गोरिदम अक्सर सेंसर से मिले रॉ डेटा की फिर से व्याख्या करते हैं. डिवाइस, पिछले कुछ घंटों में इकट्ठा की गई रीडिंग को फिर से बकेट करता है. डिवाइस के फिर से सिंक होने पर, नए डेटा पॉइंट अपलोड हो जाते हैं. इनके शुरू और खत्म होने की सीमाएं, पहले से सेव किए गए इंटरवल से ओवरलैप हो सकती हैं.
उदाहरण के लिए, स्मार्टवॉच पहनने वाले किसी ऐसे उपयोगकर्ता के बारे में सोचें जिसकी गतिविधि से जुड़ा डेटा, लगातार दो बैच में सिंक किया गया है:
- पहली बार सिंक करने के दौरान, डिवाइस
10:00:00Zसे10:14:59Zतक का डेटा पॉइंट अपलोड करता है. - उपयोगकर्ता के डिवाइस पर फिर से हिसाब लगाने के बाद, दूसरा सिंक
10:14:00Zसे10:28:59Zतक के डेटा पॉइंट को अपलोड करता है.
दोनों रिकॉर्ड, Google Health के बैकएंड में अलग-अलग सेव किए जाते हैं. इस वजह से, दोनों डेटा पॉइंट में 10:14:00Z से 10:14:59Z तक का इंटरवल शामिल होता है.
कच्चे रिकॉर्ड के लिए क्वेरी करने पर, 59 सेकंड का ओवरलैप होता है.
तुलना करने और समाधान करने वाले एंडपॉइंट
list या reconcile एंडपॉइंट का इस्तेमाल करके, एक-दूसरे से ओवरलैप होने वाले इन इंटरवल को मैनेज किया जा सकता है. अपने ऐप्लिकेशन की ज़रूरी शर्तों के हिसाब से एंडपॉइंट चुनें:
| सुविधा | list एंडपॉइंट |
reconcile एंडपॉइंट |
|---|---|---|
| एचटीटीपी मेथड | GET https://health.googleapis.com/v4/users/me/dataTypes/<var>dataType</var>/dataPoints |
GET https://health.googleapis.com/v4/users/me/dataTypes/<var>dataType</var>/dataPoints:reconcile |
| ओवरलैप करने का तरीका | यह फ़ंक्शन, सेव किए गए सभी रिकॉर्ड को अपलोड किए गए रिकॉर्ड के तौर पर दिखाता है. इसमें डुप्लीकेट रिकॉर्ड शामिल नहीं होते. इंटरवल के ओवरलैप होने पर, दोनों रिकॉर्ड दिखाए जाते हैं. | यह कुकी, अलग-अलग डिवाइसों और सिंक सेशन में मौजूद एक जैसे रिकॉर्ड के बीच के अंतर को मिटाती है. साथ ही, उन्हें एक ही स्ट्रीम में सिंक करती है. |
| फ़ायदे | यह हर डिवाइस और सिंक बैच से अपलोड किए गए हर रिकॉर्ड का पूरा और बिना बदलाव वाला ऑडिट ट्रेल उपलब्ध कराता है. | यह टाइमलाइन रेंडरिंग और अवधि की गणना को आसान बनाता है. ऐसा इसलिए, क्योंकि यह ओवरलैप होने वाले इंटरवल और मल्टी-डिवाइस के बीच होने वाले टकरावों को अपने-आप हैंडल करता है. |
| नुकसान | आपके ऐप्लिकेशन की यह ज़िम्मेदारी है कि वह एक ही समय पर कई बार नींद का डेटा इकट्ठा होने, मल्टी-डिवाइस पर डेटा इकट्ठा होने, और डिवाइस को कलाई से हटाने के दौरान डेटा इकट्ठा होने की समस्याओं का पता लगाए और उन्हें ठीक करे. | जवाब में, एक जैसे सबऑर्डिनेट रिकॉर्ड शामिल नहीं किए जाते. इसलिए, अलग-अलग डिवाइसों के सिंक बैच की अलग से ऑडिट नहीं की जा सकती. |
reconcile एंडपॉइंट को उपयोगकर्ता इंटरफ़ेस बनाने, गतिविधि की टाइमलाइन रेंडर करने, और बिना ओवरलैप वाली अवधि के कुल समय का हिसाब लगाने के लिए डिज़ाइन किया गया है. इससे, फिर से बकेट किए गए सिंक सेशन के बीच टकराव वाले इंटरवल की समस्या हल हो जाती है. यह एक साथ कई डिवाइसों पर लॉग की गई गतिविधि का भी मिलान करता है. जैसे, घड़ी और फ़ोन.
रिकॉन्सिलिएशन, सेशन के टकराव को हल करता है. इसके लिए, वह आर्टिफ़िशियल टाइम यूनियन को सिंथेसाइज़ करने के बजाय, आधिकारिक रिकॉर्ड चुनता है. उदाहरण के लिए, यह 11:00:00Z से 11:30:00Z और 11:20:00Z से 11:50:00Z को 11:00:00Z से 11:50:00Z में नहीं मिलाता. मिलान किए गए जवाब में, सबसे ज़्यादा स्कोर वाले डेटा पॉइंट को उसके मूल रिकॉर्ड किए गए इंटरवल के साथ दिखाया जाता है. इससे उस सेशन की मेज़र की गई टेलीमेट्री और मेट्रिक की विश्वसनीयता बनी रहती है.
तीसरी इमेज में दिखाया गया है कि reconcile एंडपॉइंट, ओवरलैप होने वाले सेशन को कैसे मैनेज करता है.
यह आर्टिफ़िशियल टाइम यूनियन बनाने के बजाय, आधिकारिक रिकॉर्ड चुनता है.
एंडपॉइंट गाइड में, अनुरोध और जवाब के उदाहरण दिए गए हैं. reconcile आउटपुट के साथ रॉ list रिकॉर्ड की तुलना करने के लिए, इंटरवल डेटा का मेल-मिलाप किया गया व्यू पाएं लेख पढ़ें.
list एंडपॉइंट को डिवाइस की परफ़ॉर्मेंस से जुड़ी जानकारी और डेटा ऑडिट के लिए डिज़ाइन किया गया है. इसका इस्तेमाल तब करें, जब आपके वर्कफ़्लो में हर डिवाइस से अपलोड किए गए, बिना बदलाव वाले रिकॉर्ड की जांच करना ज़रूरी हो. list का इस्तेमाल करके क्वेरी करते समय, आपके क्लाइंट लॉजिक को रॉ डेटा में इंटरवल के किसी भी ओवरलैप को मैनेज करना होगा.
टाइमस्टैंप में बदलाव करने की सुविधा और मालिक के अपडेट
कनेक्ट किए गए डिवाइस, सामान्य सिंक साइकल के दौरान सेव किए गए टाइमस्टैंप में बदलाव नहीं करते हैं. हालांकि, इंटरवल के टाइमस्टैंप (startTime और endTime) सभी डेटा सोर्स के लिए, एक जैसे नहीं होते. किसी रिकॉर्ड के फ़ील्ड में बदलाव सिर्फ़ उसका ओरिजनल क्रिएटर या मालिक कर सकता है. अन्य ऐप्लिकेशन, उन डेटा पॉइंट में बदलाव नहीं कर सकते जिन्हें उन्होंने नहीं बनाया है.
मालिक ऐप्लिकेशन, अपने मौजूदा रिकॉर्ड अपडेट करने के लिए patch एंडपॉइंट का इस्तेमाल कर सकता है. इसमें शुरू या खत्म होने के टाइमस्टैंप में बदलाव करना शामिल है.
PATCH का इस्तेमाल करके टाइमस्टैंप अपडेट करने का उदाहरण देखने के लिए, एंडपॉइंट गाइड में मौजूदा डेटा के लिए अपडेट इंटरवल के टाइमस्टैंप अपडेट करना देखें.
इसी तरह, Health Connect या पार्टनर ऐप्लिकेशन जैसे बाहरी प्लैटफ़ॉर्म से सिंक किए गए डेटा पॉइंट, ओरिजनल सोर्स से अपडेट पाते हैं. जब मूल ऐप्लिकेशन किसी मौजूदा रिकॉर्ड में बदलाव करता है, तो वे अपडेट Google Health पर दिखते हैं.