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 में डेटा लिखना (Google Health API में कॉपी करना). इन कार्रवाइयों को किसी खास क्रम में बार-बार करना, सिंक लाइफ़साइकल कहलाता है.

पहली इमेज में, स्टैंडर्ड सिंक लाइफ़साइकल दिखाया गया है. इसमें पढ़ने और लिखने की कार्रवाइयां शामिल हैं. इसमें पहले बताई गई किसी भी वजह को ध्यान में नहीं रखा गया है.

लिखें

1. लिखने के लिए नया डेटा तैयार करना — किसी बाहरी डिवाइस या ऐप्लिकेशन से डेटा ट्रांसफ़र करना और डेटा पॉइंट को JSON फ़ॉर्मैट में बदलना, ताकि वे Google Health API के डेटा टाइप के साथ काम कर सकें. ध्यान दें कि फ़िलहाल Health API में, लिखने के लिए क्लाइंट-असाइन किए गए कस्टम आईडी की सुविधा उपलब्ध नहीं है. ऐसे आईडी, POST में दिए जा सकते हैं, लेकिन उन्हें अनदेखा कर दिया जाता है.
2. रिकॉर्ड अपसर्ट करना — REST एंडपॉइंट का इस्तेमाल करके, Google Health API में डेटा पॉइंट सबमिट करना. रिकॉर्ड बनाने के लिए POST और मौजूदा रिकॉर्ड डालने और अपडेट करने के लिए PATCH का इस्तेमाल करें. PATCH कार्रवाई के लिए ज़रूरी आईडी, पिछली POST कार्रवाई (पिछली साइकल में अगला चरण) से मिले होंगे.
3. दिखाए गए संसाधन आईडी प्रोसेस करना — सर्वर से जनरेट किए गए आईडी का इस्तेमाल करते समय, सर्वर से मिले संसाधन के name या आईडी को अपने डेवलपर डेटास्टोर में एक्सट्रैक्ट और सेव करें, ताकि आने वाले समय में उन्हें अपडेट (PATCH) या मिटाया (DELETE) जा सके. इन दोनों टाइप के बारे में ज़्यादा जानने के लिए, पहचान की रणनीतियां देखें.

पढ़ें

1. रिकॉर्ड पढ़ना — REST एंडपॉइंट (filter क्वेरी पैरामीटर और pageToken पेज पर नंबर डालने की सुविधा के साथ GET, या rollUp और dailyRollUp जैसे एग्रीगेशन एंडपॉइंट) का इस्तेमाल करके, Google Health API में मौजूद नए डेटा और मौजूदा डेटा में किए गए बदलावों को फ़ेच करना. इसके अलावा, Webhook की सदस्यता (projects.subscribers) का इस्तेमाल करके, रीयल-टाइम सूचनाएं पाना. सूचना से सिर्फ़ यह पता चलता है कि नया डेटा उपलब्ध है. इससे यह पता नहीं चलता कि असल में डेटा क्या है.
2. डेवलपर डेटास्टोर को फिर से मिलाना — नए और अपडेट किए गए डेटा को अपने डेवलपर डेटास्टोर से फिर से मिलाएं.

इसके बाद, यह साइकल बाहरी डिवाइसों या ऐप्लिकेशन की खास ज़रूरतों के हिसाब से, तय समय के अंतराल पर दोहराई जाती है. आम तौर पर, हमारा सुझाव है कि अपने डेटास्टोर और Google Health API के बीच डेटा सिंक करने के लिए, इसी क्रम का इस्तेमाल किया जाए.

पहचान की रणनीतियां

अगर आपको Google Health API में डेटा लिखना है, तो Google Health API के साथ इंटिग्रेशन बनाने से पहले, आपको डेटा पॉइंट (डेटा की बुनियादी यूनिट) बनाते समय, संसाधन की पहचान करने की रणनीति चुननी होगी.

फ़िलहाल Health API में, लिखने के लिए क्लाइंट-असाइन किए गए आईडी की सुविधा उपलब्ध नहीं है. ऐसे आईडी, POST में दिए जा सकते हैं, लेकिन उन्हें अनदेखा कर दिया जाता है. इस विकल्प के बारे में जानकारी यहां दी गई है.

1. सर्वर से जनरेट किए गए आईडी (डिफ़ॉल्ट विकल्प): क्लाइंट, आईडी के बिना डेटा सबमिट करता है. इसके बाद, Google Health API का बैकएंड, सिस्टम का यूनीक आइडेंटिफ़ायर जनरेट करके दिखाता है.
2. क्लाइंट-असाइन किए गए कस्टम आईडी (per AIP-133, फ़िलहाल उपलब्ध नहीं): क्लाइंट ऐप्लिकेशन, यूनीक आइडेंटिफ़ायर (उदाहरण के लिए, UUID या लोकल डेटाबेस की प्राइमरी की) जनरेट करता है और इसे बनाते समय, संसाधन के पाथ में उपलब्ध कराता है.

नीचे दी गई टेबल में, पहचान की दोनों रणनीतियों की तुलना की गई है. इससे आपको अपने इंटिग्रेशन के लिए सही तरीका चुनने में मदद मिलेगी:

सुविधा	सर्वर से जनरेट किए गए आईडी	क्लाइंट-असाइन किए गए कस्टम आईडी
आईडी जनरेट करना	`POST` को एक्ज़ीक्यूट करते समय, सर्वर रैंडम सिस्टम आईडी जनरेट करता है.	क्लाइंट, लिखने से पहले स्थानीय तौर पर स्टेबल आईडी (UUID v4 / इंटरनल पीके) जनरेट करता है.
संसाधन का पाथ	.../dataPoints/{server_id} (जवाब में दिखाया गया)	.../dataPoints/{custom_id}
लिखने के बाद स्थानीय तौर पर किया जाने वाला चरण	ज़रूरी है. आने वाले समय में अपडेट/मिटाने की सुविधा चालू करने के लिए, स्थानीय डेटाबेस में दिखाए गए server_id को सेव करना ज़रूरी है.	ज़रूरी नहीं है. ऐप्लिकेशन के पास पहले से ही आईडी है.
आईडी मैपिंग टेबल	ज़रूरी है. क्लाइंट को दो-तरफ़ा मैपिंग (local_id ↔ server_id) बनाए रखनी होगी.	ज़रूरी नहीं है. क्लाइंट, सीधे अपनी प्राइमरी की का इस्तेमाल करता है.
फिर से कोशिश करने का तरीका (कमज़ोर नेटवर्क)	डुप्लीकेट बनने का खतरा. टाइम आउट हो चुके POST के लिए फिर से कोशिश करने पर, नए सर्वर आईडी के साथ डुप्लीकेट रिकॉर्ड बन जाता है.	सुरक्षित और आइडमपोटेंट. एक ही custom_id के साथ POST के लिए फिर से कोशिश करने पर, डुप्लीकेट नहीं बनता. इसके बजाय, 409 ALREADY_EXISTS दिखता है.
ऑफ़लाइन सिंक की सुविधा	सीमित. संसाधन आईडी का रेफ़रंस देने से पहले, उन्हें पाने के लिए सर्वर के जवाब का इंतज़ार करना ज़रूरी है.	पूरी तरह से. स्टेबल आईडी की मदद से, ऑफ़लाइन होने पर भी इकाइयां बनाई और बदली जा सकती हैं. इसके बाद, इंटरनेट से कनेक्ट होने पर उन्हें आसानी से सिंक किया जा सकता है.
फ़ॉर्मैट से जुड़ी पाबंदियां	इन्हें पूरी तरह से सर्वर मैनेज करता है.	^[a-z0-9-]{4,63}$ (छोटे अक्षरों और अंकों के साथ 4–63 वर्ण और हाइफ़न) का पालन करना ज़रूरी है.
कब चुनें	सर्वर से जनरेट किए गए आईडी तब चुनें, जब: आपका ऐप्लिकेशन सिर्फ़ लिखने / जोड़ने की अनुमति वाला हो.जैसे, टेलीमेट्री या कदमों की संख्या भेजना. इन्हें बाद में कभी अपडेट या मिटाया नहीं जाता. आपका ऐप्लिकेशन, डेटा के अलग-अलग पॉइंट का स्थानीय परसिस्टेंट डेटाबेस नहीं रखता. आपको स्ट्रिंग की पुष्टि करने से जुड़ी पाबंदियों (जैसे, 4-63 वर्ण) को मैनेज किए बिना, आसान तरीका चाहिए.	कस्टम आईडी तब चुनें, जब: आपके पास दो-तरफ़ा सिंक वाला कोई ऐप्लिकेशन हो, जो अलग-अलग डिवाइसों पर स्वास्थ्य से जुड़े रिकॉर्ड पढ़ता, लिखता, और अपडेट करता हो. आपके ऐप्लिकेशन में स्थानीय डेटाबेस (जैसे, Room या SQLite) हो, जिसमें स्थानीय प्राइमरी की के साथ रिकॉर्ड सेव किए जाते हों. आपके उपयोगकर्ता, ऑफ़लाइन होने पर या रुक-रुक कर मिलने वाले मोबाइल कनेक्शन पर डेटा रिकॉर्ड करते हों. ऐसे में, सुरक्षित तरीके से फिर से कोशिश करना ज़रूरी होता है. आपको अपने बैकएंड डेटाबेस और एपीआई के बीच, आईडी मैपिंग टेबल की ज़रूरत न हो.

सिर्फ़ पढ़ने की अनुमति वाला सिंक लाइफ़साइकल

दूसरी इमेज: Google Health API में सिर्फ़ पढ़ने की अनुमति वाला सिंक लाइफ़साइकल

Google Health API से सिर्फ़ डेटा पढ़ने वाले ऐप्लिकेशन को, अपने डेवलपर डेटास्टोर में डेटा कॉपी करना होगा. साथ ही, लाइफ़साइकल के मेल-मिलाप वाले हिस्से को मैनेज करना होगा.

यहां, 'डेटा पढ़ना' सेक्शन में बताए गए टास्क लागू होते हैं.

दूसरी इमेज में, सिर्फ़ पढ़ने की अनुमति वाला लाइफ़साइकल दिखाया गया है.