Google Health API, एक नया एपीआई है. इसे शुरू से बनाया गया है. इससे डेवलपर, Fitbit के उपयोगकर्ता के डेटा के बारे में क्वेरी कर सकते हैं. यह सिर्फ़ एक अपडेट नहीं है, बल्कि एक रणनीतिक फ़ैसला है. इससे यह पक्का किया जा सकेगा कि आपके ऐप्लिकेशन सुरक्षित और भरोसेमंद हों. साथ ही, स्वास्थ्य से जुड़ी टेक्नोलॉजी में होने वाली आने वाली तरक्की के लिए तैयार हों. यह एपीआई, ऐप्लिकेशन रजिस्टर करने के लिए नई कंसोल, Google OAuth 2.0 की सुविधा, नए डेटा टाइप, नए एंडपॉइंट स्कीमा, और नए जवाब फ़ॉर्मैट के साथ काम करता है.
इस गाइड को इसलिए बनाया गया है, ताकि डेवलपर अपने मौजूदा Fitbit Web API ऐप्लिकेशन को नए Google Health API पर माइग्रेट कर सकें.
आपको माइग्रेट क्यों करना चाहिए?
Google Health API का इस्तेमाल करने के ये फ़ायदे हैं:
- बेहतर सुरक्षा: Google के सुरक्षा से जुड़े सबसे सही तरीकों का पालन करना. साथ ही, Google के सुरक्षा, निजता, और पहचान से जुड़े मानकों के मुताबिक काम करना.
- डेटा में एकरूपता: यह डेटा फ़ॉर्मैट, टाइम ज़ोन, मेज़रमेंट यूनिट, और गड़बड़ी ठीक करने के तरीके में एकरूपता लाता है. इससे डेवलपर को बेहतर अनुभव मिलता है.
- स्केलेबिलिटी और आने वाले समय के लिए तैयार: इसे आने वाले समय की ज़रूरतों को पूरा करने के लिए डिज़ाइन किया गया है. साथ ही, यह gRPC जैसे आधुनिक प्रोटोकॉल के साथ काम करता है.
अपने उपयोगकर्ताओं को माइग्रेट करना
Fitbit Web API से Google Health API पर माइग्रेट करना, सिर्फ़ एक तकनीकी अपडेट नहीं है. OAuth लाइब्रेरी में बदलाव होने की वजह से, आपके उपयोगकर्ताओं को नए इंटिग्रेशन के लिए फिर से सहमति देनी होगी. ऐक्सेस टोकन और रीफ़्रेश टोकन को Google Health API में ट्रांसफ़र नहीं किया जा सकता. माइग्रेशन के दौरान उपयोगकर्ताओं को बनाए रखने में आपकी मदद करने के लिए, यहां माइग्रेशन को सही तरीके से पूरा करने से जुड़े कुछ तकनीकी और रणनीतिक सुझाव दिए गए हैं.
दो लाइब्रेरी वाली रणनीति
Fitbit Web API और Google Health API, दोनों अलग-अलग OAuth2 लाइब्रेरी का इस्तेमाल करते हैं. इसलिए, आपको "ब्रिजिंग" अवधि को मैनेज करना होगा. इस दौरान, दोनों लाइब्रेरी आपके कोडबेस में मौजूद रहेंगी.
पैरलल ऑथराइज़ेशन मैनेजमेंट
- Encapsulate Clients: Create an abstraction layer or interface for your "Health Service." इससे आपके ऐप्लिकेशन के बाकी हिस्से को डेटा का अनुरोध करने की अनुमति मिलती है. इसके लिए, यह जानना ज़रूरी नहीं है कि उस उपयोगकर्ता के लिए कौनसी लाइब्रेरी (Fitbit OAuth बनाम Google OAuth) चालू है.
- डेटाबेस स्कीमा अपडेट: अपनी उपयोगकर्ता टेबल को अपडेट करके, उसमें
oauth_typeफ़्लैग शामिल करें. उदाहरण के लिए, Fitbit OAuth के लिएfitbitऔर Google OAuth के लिएgoogleका इस्तेमाल करें.- नए उपयोगकर्ता: डिफ़ॉल्ट रूप से Google Health API और Google OAuth लाइब्रेरी का इस्तेमाल करते हैं.
oauth_typeकोgoogleपर सेट करें. - मौजूदा उपयोगकर्ता: जब तक वे सहमति देने की प्रोसेस पूरी नहीं कर लेते, तब तक Fitbit Web API का इस्तेमाल करते रहें.
oauth_typeकोfitbitपर सेट करें.
- नए उपयोगकर्ता: डिफ़ॉल्ट रूप से Google Health API और Google OAuth लाइब्रेरी का इस्तेमाल करते हैं.
"स्टेप-अप" के लिए, सहमति लेने की प्रोसेस
लॉग आउट करने के लिए मजबूर करने के बजाय, इंक्रीमेंटल ऑथराइज़ेशन का इस्तेमाल करें:
- Fitbit के ओपन सोर्स टोकन का पता लगाना: जब Fitbit Web API का कोई उपयोगकर्ता ऐप्लिकेशन खोलता है, तब "सेवा से जुड़ा अपडेट" सूचना ट्रिगर करें.
- Google OAuth फ़्लो लॉन्च करें: जब उपयोगकर्ता "अपडेट करें" पर क्लिक करता है, तो Google OAuth2 लाइब्रेरी फ़्लो शुरू करें.
- बदलें और रद्द करें: Google OAuth टोकन मिलने के बाद, उसे उपयोगकर्ता की प्रोफ़ाइल में सेव करें. साथ ही,
fitbitकोgoogleमें अपडेट करें और (अगर हो सके) प्रोग्राम के हिसाब से पुरानेfitbitटोकन को रद्द करें, ताकि उपयोगकर्ता की सुरक्षा प्रोफ़ाइल को सुरक्षित रखा जा सके.oauth_type
ज़्यादा से ज़्यादा उपयोगकर्ताओं को अपने साथ जोड़े रखना
फिर से सहमति लेने की प्रोसेस, चर्न के लिए "खतरे वाली स्थिति" होती है. उपयोगकर्ताओं को ऐप्लिकेशन का इस्तेमाल बंद करने से रोकने के लिए, UX से जुड़े इन सबसे सही तरीकों को अपनाएं:
"वैल्यू-फ़र्स्ट" कम्यूनिकेशन
"हमने अपने एपीआई को अपडेट कर दिया है" से शुरुआत न करें. Google की मदद से तैयार किए गए नए सिस्टम के फ़ायदों के बारे में बताएं:
- बेहतर सुरक्षा: Google के इंडस्ट्री-लीडिंग खाते की सुरक्षा और 2FA के बारे में बताएं.
- भरोसेमंद: डेटा को तेज़ी से सिंक किया जा सकता है और डेटा कनेक्शन ज़्यादा स्थिर होते हैं.
- सुविधा को सीमित तौर पर उपलब्ध कराना: उपयोगकर्ताओं को यह जानकारी देना कि नई सुविधाओं और डेटा टाइप के लिए अपडेट ज़रूरी है.
स्मार्ट टाइमिंग
- अहम टास्क के बीच में सहमति लेने के लिए स्क्रीन न दिखाएं: जब कोई व्यक्ति कसरत कर रहा हो या खाने-पीने की चीज़ों की जानकारी लॉग कर रहा हो, तब सहमति लेने के लिए स्क्रीन न दिखाएं.
- "नज" फ़ेज़: पहले 30 दिनों के लिए, खारिज किए जा सकने वाले बैनर का इस्तेमाल करें.
- "हार्ड कटऑफ़" फ़ेज़: सहमति लेने की प्रोसेस को सिर्फ़ तब ज़रूरी बनाएं, जब चेतावनी देने के कई हफ़्ते बीत चुके हों. ऐसा Fitbit Web API के बंद होने की आधिकारिक समयसीमा के साथ करें.
माइग्रेशन फ़्लो की तुलना
पुराने और नए फ़्लो के बीच विज़ुअल अंतर से, डेवलपर को यह समझने में मदद मिलती है कि लॉजिक कहां से शुरू होता है.
| सुविधा | Fitbit Web API (लेगसी) | Google Health API (Google-Identity) |
| पुष्टि करने वाली लाइब्रेरी | स्टैंडर्ड ओपन सोर्स | Google Identity Services (GIS) / Google Auth |
| उपयोगकर्ता खाते | Fitbit के लेगसी क्रेडेंशियल | Google खाता |
| टोकन का टाइप | Fitbit के लिए खास तौर पर ऐक्सेस / रीफ़्रेश करना | Google से जारी किए गए ऐक्सेस/रीफ़्रेश टोकन |
| स्कोप मैनेजमेंट | ज़्यादा अनुमतियां | ज़्यादा बेहतर / धीरे-धीरे मिलने वाली अनुमतियां |
खाता माइग्रेशन से जुड़ी बारीकियों को मैनेज करना
Fitbit के दस्तावेज़ के मुताबिक, अपने खाते को Google पर माइग्रेट करने वाले उपयोगकर्ताओं के तीसरे पक्ष के कनेक्शन आम तौर पर तुरंत नहीं हटते. हालांकि, एपीआई वर्शन को बदलना डेवलपर के लिए ज़रूरी है.
- टोकन के मान्य होने की जांच करना: बैकग्राउंडवर्कर का इस्तेमाल करके यह जांच करें कि Fitbit टोकन, "अनुमति नहीं है" गड़बड़ियों की वजह से काम नहीं कर रहे हैं या नहीं. इससे पता चल सकता है कि उपयोगकर्ता ने अपना खाता माइग्रेट कर लिया है, लेकिन आपका ऐप्लिकेशन अब तक अपडेट नहीं हुआ है.
- ग्रेसफ़ुल फ़ेलियर: अगर Fitbit OAuth कॉल काम नहीं करता है, तो उपयोगकर्ता को "Fitbit से फिर से कनेक्ट करें" पेज पर रीडायरेक्ट करें. यह पेज, खास तौर पर नए Google OAuth फ़्लो का इस्तेमाल करता है.