वेबबुक की सदस्यताएं

Google Health API की मदद से, आपका ऐप्लिकेशन रीयल-टाइम में सूचनाएं पा सकता है. ये सूचनाएं तब मिलती हैं, जब किसी उपयोगकर्ता के सेहत के डेटा में बदलाव होता है. Google Health API में डेटा उपलब्ध होने के तुरंत बाद, आपका सर्वर बदलावों के लिए पोल करने के बजाय, एचटीटीपीएस पोस्ट अनुरोध वेबहुक पाता है.

डेटा टाइप, जो इस्तेमाल किए जा सकते हैं

वेबहुक सूचनाएं, इन डेटा टाइप के लिए उपलब्ध हैं:

  • ऐक्टिव ज़ोन मिनट
  • गतिविधि का लेवल
  • ऊंचाई
  • ब्लड ग्लूकोज़
  • बॉडी फ़ैट
  • धड़कन की दर वाले ज़ोन में बर्न की गई कैलोरी
  • धड़कन की दर में रोज़ाना होने वाला उतार-चढ़ाव
  • धड़कन की दर वाले ज़ोन की रोज़ाना की जानकारी
  • ऑक्सीजन की मात्रा का रोज़ का डेटा
  • सांस की दर का रोज़ का डेटा
  • आराम करते समय धड़कन की रोज़ाना की दर
  • नींद के दौरान रोज़ाना के तापमान में होने वाले बदलाव
  • दूरी
  • कसरत
  • फ़्लोर
  • धड़कन की दर
  • धड़कन की दर में उतार-चढ़ाव
  • ऊंचाई
  • हाइड्रेशन का लॉग
  • पोषण से जुड़ा डेटा लॉग करना
  • नींद के दौरान सांस की दर की खास जानकारी
  • दौड़ने के दौरान का Vo2 मैक्स
  • एक ही जगह पर बैठे या लेटे रहने की अवधि
  • नींद
  • चरण
  • हार्ट रेट ज़ोन में बिताया गया समय
  • वज़न

इन डेटा टाइप के लिए सूचनाएं सिर्फ़ तब भेजी जाती हैं, जब किसी उपयोगकर्ता ने इनमें से किसी एक स्कोप के लिए सहमति दी हो:

  • गतिविधि, जिसमें कदमों की संख्या, ऊंचाई, दूरी, और फ़्लोर के डेटा टाइप शामिल हैं:
    • https://www.googleapis.com/auth/googlehealth.activity_and_fitness.readonly
    • https://www.googleapis.com/auth/googlehealth.activity_and_fitness.writeonly
  • सेहत की मेट्रिक, जिसमें वज़न का डेटा टाइप शामिल है:
    • https://www.googleapis.com/auth/googlehealth.health_metrics_and_measurements.readonly
    • https://www.googleapis.com/auth/googlehealth.health_metrics_and_measurements.writeonly
  • नींद, जिसमें नींद का डेटा टाइप शामिल है:
    • https://www.googleapis.com/auth/googlehealth.sleep.readonly
    • https://www.googleapis.com/auth/googlehealth.sleep.writeonly

IAM सेवा खाते

हालांकि, Google Health API के लिए सदस्यों को कॉन्फ़िगर करते समय, IAM सेवा खाते का इस्तेमाल करना ज़रूरी नहीं है. फिर भी, हमारा सुझाव है कि आप इसका इस्तेमाल करें. सेवा खाते, ऐप्लिकेशन के वर्कलोड के लिए स्टैंडर्ड उपयोगकर्ता खातों की तुलना में बेहतर सुरक्षा देते हैं. ऐसा इन सुविधाओं की वजह से होता है:

  • कम समय के लिए मान्य क्रेडेंशियल अपने-आप जनरेट होना: Google Cloud के किसी एक्ज़ीक्यूशन एनवायरमेंट (जैसे कि Compute Engine, Cloud Run या Google Kubernetes Engine) से अटैच होने पर, सेवा खातों को सुरक्षित और कम समय के लिए मान्य क्रेडेंशियल अपने-आप मिल जाते हैं. साथ ही, ये क्रेडेंशियल समय-समय पर बदलते रहते हैं. इससे, स्थायी स्टैटिक कुंजियों को मैनेज और सेव करने से जुड़े जोखिम खत्म हो जाते हैं.
  • कम से कम अधिकारों का सिद्धांत: सेवा खाते, वर्कलोड के लिए खास पहचान देते हैं. उन्हें सिर्फ़ उन अनुमतियों को दिया जा सकता है जिनकी ज़रूरत सदस्य के एंडपॉइंट को मैनेज करने के लिए होती है. इससे उन्हें आपके Google Cloud संसाधनों का ज़्यादा ऐक्सेस नहीं मिलता.
  • लाइफ़साइकल की स्वतंत्रता: सेवा खाते, किसी भी उपयोगकर्ता के खाते से अलग काम करते हैं. इससे यह पक्का होता है कि कर्मचारियों के बदलने से, लंबे समय तक पुष्टि करने की सुविधा पर कोई असर नहीं पड़ता.

सेवा खाता सेट अप करना

किसी सेवा खाते का इस्तेमाल करके पुष्टि करने के लिए, अपने सदस्य ऐप्लिकेशन को कॉन्फ़िगर करने के लिए:

  1. सेवा खाता बनाएं: Google Cloud Console में, अपने प्रोजेक्ट के आईएएम और एडमिन पेज पर जाएं. इसके बाद, उपयोगकर्ता की ओर से मैनेज किया जाने वाला नया सेवा खाता बनाएं.
  2. ज़रूरी IAM भूमिकाएं असाइन करें: सेवा खाते को वे भूमिकाएं असाइन करें जो आपके Google Cloud प्रोजेक्ट पर सदस्यों को मैनेज करने के लिए ज़रूरी हैं.
  3. अपने वर्कलोड में सेवा खाता अटैच करें: अपने एनवायरमेंट को कॉन्फ़िगर करें, ताकि वह नए सेवा खाते के तौर पर काम कर सके. इस एनवायरमेंट में, सदस्य के लॉजिक को होस्ट किया जाता है. इससे आपका ऐप्लिकेशन कोड (जैसे, Google API क्लाइंट लाइब्रेरी), projects.subscribers REST API को कॉल करते समय, सेवा खाते के कुछ समय के लिए मान्य क्रेडेंशियल का अपने-आप पता लगा सकता है और उनका इस्तेमाल कर सकता है.

सीपीई की भूमिकाएं

Google Health API के सदस्यों या सदस्यताओं को मैनेज करने के लिए, आपको एपीआई कॉल करने वाले सेवा खाते को सही भूमिका देनी होगी. ज़रूरत के हिसाब से ऐक्सेस लेवल तय करें और इनमें से कोई एक भूमिका असाइन करें:

  • Google Health API Read
  • Google Health API Editor
  • Google Health API एडमिन

Google Health API के लिए, IAM की भूमिकाओं और अनुमतियों के बारे में ज़्यादा जानें.

सदस्यों को मैनेज करना

सूचनाएं पाने के लिए, आपको एक सदस्य रजिस्टर करना होगा. यह आपके ऐप्लिकेशन के सूचना एंडपॉइंट को दिखाता है. सदस्यों को मैनेज करने के लिए, projects.subscribers पर उपलब्ध REST API का इस्तेमाल किया जा सकता है.

आपके सदस्य के एंडपॉइंट को एचटीटीपीएस (TLSv1.2+) का इस्तेमाल करना चाहिए. साथ ही, इसे सार्वजनिक तौर पर ऐक्सेस किया जा सकता हो. सदस्यता लेने वाले व्यक्ति का खाता बनाते समय और उसे अपडेट करते समय, Google Health API पुष्टि करने से जुड़ी चुनौती देता है. इससे यह पक्का किया जाता है कि आपके पास एंडपॉइंट यूआरआई का मालिकाना हक है. पुष्टि न होने पर, सदस्य बनाने और अपडेट करने की कार्रवाइयां FailedPreconditionException के साथ पूरी नहीं होती हैं.

सदस्यता लेने वाला व्यक्ति बनाना

अपने प्रोजेक्ट के लिए किसी नए सदस्य को रजिस्टर करने के लिए, create एंडपॉइंट का इस्तेमाल करें. आपको यह जानकारी देनी होगी:

  • project-id: वह प्रोजेक्ट नंबर जहां वेबुक सेवा खाता बनाया गया था.
  • subscriberId: यह एक यूनीक आइडेंटिफ़ायर है, जिसे आपको सदस्य के लिए उपलब्ध कराना होता है. यह आईडी 4 से 36 वर्णों के बीच होना चाहिए. साथ ही, यह रेगुलर एक्सप्रेशन ([a-z]([a-z0-9-]{2,34}[a-z0-9])) से मेल खाना चाहिए.
  • endpointUri: वेबहुक सूचनाओं के लिए डेस्टिनेशन यूआरएल.
  • subscriberConfigs: आपको जिन डेटा टाइप के लिए सूचनाएं चाहिए और हर डेटा टाइप के लिए सदस्यता की नीति.
  • endpointAuthorization: आपके एंडपॉइंट के लिए ऑथराइज़ेशन मेकेनिज़्म. इसमें आपके दिए गए secret का इस्तेमाल किया जाना चाहिए. secret की वैल्यू, हर सूचना वाले मैसेज के साथ Authorization हेडर में भेजी जाती है. इस टोकन का इस्तेमाल करके, यह पुष्टि की जा सकती है कि आने वाले अनुरोध, Google Health API से किए गए हैं. उदाहरण के लिए, Bearer authentication के लिए secret को Bearer R4nd0m5tr1ng123 पर सेट किया जा सकता है या Basic authentication के लिए Basic dXNlcjpwYXNzd29yZA== पर सेट किया जा सकता है.

subscriberConfigs में, आपको हर डेटा टाइप के लिए subscriptionCreatePolicy सेट करना होगा. अपने-आप होने वाली सदस्यताओं का इस्तेमाल करने के लिए, इसे AUTOMATIC पर सेट करें. अगर आपको उपयोगकर्ता की सदस्यताओं को खुद मैनेज करना है, तो इसे MANUAL पर सेट करें. हर विकल्प के बारे में ज़्यादा जानने के लिए, अपने-आप होने वाली सदस्यताएं और मैन्युअल सदस्यताएं देखें.

अनुरोध

POST https://health.googleapis.com/v4/projects/project-id/subscribers?subscriberId=subscriber-id
{
  "endpointUri": "https://myapp.com/webhooks/health",
  "subscriberConfigs": [
    {
      "dataTypes": ["steps", "altitude", "distance", "floors", "weight"],
      "subscriptionCreatePolicy": "AUTOMATIC"
    },
    {
      "dataTypes": ["sleep"],
      "subscriptionCreatePolicy": "MANUAL"
    }
  ],
  "endpointAuthorization": {
    "secret": "Bearer example-secret-token"
  }
}

जवाब

{
  "name": "projects/project-id/subscribers/subscriber-id",
  "endpointUri": "https://myapp.com/webhooks/health",
  "subscriberConfigs": [
    {
      "dataTypes": ["steps", "altitude", "distance", "floors", "weight"],
      "subscriptionCreatePolicy": "AUTOMATIC"
    },
    {
      "dataTypes": ["sleep"],
      "subscriptionCreatePolicy": "MANUAL"
    }
  ]
}

सदस्यों की सूची

अपने प्रोजेक्ट के लिए रजिस्टर किए गए सभी सदस्यों की जानकारी पाने के लिए, list एंडपॉइंट का इस्तेमाल करें.

अनुरोध

GET https://health.googleapis.com/v4/projects/project-id/subscribers

जवाब

{
  "subscribers": [
    {
      "name": "projects/project-id/subscribers/subscriber-id",
      "endpointUri": "https://myapp.com/webhooks/health",
      "subscriberConfigs": [
        {
          "dataTypes": ["steps", "altitude", "distance", "floors", "weight"],
          "subscriptionCreatePolicy": "AUTOMATIC"
        },
        {
          "dataTypes": ["sleep"],
          "subscriptionCreatePolicy": "MANUAL"
        }
      ],
      "endpointAuthorization": {
        "authorizationTokenSet": true
      }
    }
  ],
  "totalSize": 1
}

किसी सदस्य की जानकारी अपडेट करना

अपने प्रोजेक्ट में किसी सदस्य की जानकारी अपडेट करने के लिए, patch एंडपॉइंट का इस्तेमाल करें. इन फ़ील्ड को अपडेट किया जा सकता है: endpointUri, subscriberConfigs, और endpointAuthorization.

updateMask क्वेरी पैरामीटर और अनुरोध का मुख्य हिस्सा देकर, फ़ील्ड अपडेट किए जाते हैं. updateMask में, कॉमा लगाकर अलग की गई लिस्ट होनी चाहिए. इसमें उन फ़ील्ड के नाम होने चाहिए जिन्हें आपको अपडेट करना है. फ़ील्ड के नामों के लिए, कैमल केस का इस्तेमाल करें (उदाहरण के लिए, endpointUri). अनुरोध के मुख्य हिस्से में, Subscriber ऑब्जेक्ट का कुछ हिस्सा होना चाहिए. इसमें उन फ़ील्ड के लिए नई वैल्यू होनी चाहिए जिन्हें आपको अपडेट करना है. सिर्फ़ updateMask में दिए गए फ़ील्ड अपडेट किए जाते हैं. अगर आपने अनुरोध के मुख्य हिस्से में ऐसे फ़ील्ड दिए हैं जो updateMask में नहीं हैं, तो उन्हें अनदेखा कर दिया जाएगा.

endpointUri या endpointAuthorization को अपडेट करने पर, एंडपॉइंट की पुष्टि की जाती है. ज़्यादा जानकारी के लिए, एंडपॉइंट की पुष्टि करना लेख पढ़ें.

subscriberConfigs अपडेट करते समय, ध्यान दें कि यह पूरी तरह से बदल दिया जाता है, न कि मर्ज किया जाता है. अगर subscriberConfigs को updateMask में शामिल किया जाता है, तो उस सदस्य के लिए सेव किए गए सभी कॉन्फ़िगरेशन, अनुरोध के मुख्य हिस्से में दी गई सूची से बदल दिए जाते हैं. कोई कॉन्फ़िगरेशन जोड़ने या हटाने के लिए, आपको कॉन्फ़िगरेशन का पूरा सेट देना होगा. अगर आपको अन्य फ़ील्ड अपडेट करने हैं और मौजूदा कॉन्फ़िगरेशन को बनाए रखना है, तो updateMask से subscriberConfigs को हटाएं.

अनुरोध

PATCH https://health.googleapis.com/v4/projects/project-id/subscribers/subscriber-id?updateMask=endpointUri
{
  "endpointUri": "https://myapp.com/new-webhooks/health"
}

जवाब

{
  "name": "projects/project-id/subscribers/subscriber-id",
  "endpointUri": "https://myapp.com/new-webhooks/health",
  "subscriberConfigs": [
    {
      "dataTypes": ["steps", "altitude", "distance", "floors", "weight"],
      "subscriptionCreatePolicy": "AUTOMATIC"
    },
    {
      "dataTypes": ["sleep"],
      "subscriptionCreatePolicy": "MANUAL"
    }
  ]
}

किसी सदस्य को मिटाना

अपने प्रोजेक्ट से किसी सदस्य को हटाने के लिए, delete एंडपॉइंट का इस्तेमाल करें. सदस्यता रद्द करने के बाद, सदस्य को सूचनाएं नहीं मिलेंगी.

अनुरोध

DELETE https://health.googleapis.com/v4/projects/project-id/subscribers/subscriber-id

जवाब

अगर मिटाने की प्रोसेस पूरी हो जाती है, तो एचटीटीपी स्टेटस `200 OK` के साथ खाली रिस्पॉन्स बॉडी मिलती है. 
{}

एंडपॉइंट की पुष्टि

सूचनाएं डिलीवर करने की प्रोसेस को सुरक्षित और भरोसेमंद बनाने के लिए, Google Health API दो चरणों में पुष्टि करने की प्रोसेस को पूरा करता है. यह प्रोसेस तब पूरी की जाती है, जब कोई सदस्य बनाया जाता है या उसके एंडपॉइंट कॉन्फ़िगरेशन (endpointUri या endpointAuthorization) को अपडेट किया जाता है. यह प्रोसेस, एपीआई कॉल के दौरान एक साथ पूरी की जाती है. यह सेवा, आपके एंडपॉइंट यूआरआई को दो अपने-आप भेजे जाने वाले POST अनुरोध भेजती है. इसके लिए, User-Agent Google-Health-API-Webhooks और JSON बॉडी {"type": "verification"} का इस्तेमाल किया जाता है.

  • Handshake की अनुमति: पहला अनुरोध, कॉन्फ़िगर किए गए Authorization हेडर के साथ भेजा जाता है. आपके सर्वर को 200 OK या 201 Created स्टेटस के साथ जवाब देना होगा.
  • बिना अनुमति के चुनौती: दूसरा अनुरोध क्रेडेंशियल के बिना भेजा गया है. आपके सर्वर को 401 Unauthorized या 403 Forbidden स्टेटस के साथ जवाब देना होगा.

इस हैंडशेक से यह पुष्टि होती है कि आपका एंडपॉइंट चालू है और सुरक्षा को सही तरीके से लागू कर रहा है. अगर इनमें से कोई भी चरण पूरा नहीं होता है, तो एपीआई अनुरोध पूरा नहीं होगा और FAILED_PRECONDITION गड़बड़ी का मैसेज दिखेगा. इस हैंडशेक के पूरा होने के बाद ही, आपके सदस्य की जानकारी सेव की जाती है. साथ ही, उसे सेहत का डेटा पाने के लिए सूचनाएं पाने की सुविधा चालू की जाती है.

डेटा सुरक्षित करने वाली कुंजी का नया वर्शन बनाना

अगर आपको endpointAuthorization के लिए कुंजियां रोटेट करनी हैं, तो यह तरीका अपनाएं:

  1. अपने एंडपॉइंट को कॉन्फ़िगर करें, ताकि वह पुरानी और नई, दोनों endpointAuthorization वैल्यू स्वीकार कर सके.
  2. ?updateMask=endpointAuthorization के साथ patch अनुरोध का इस्तेमाल करके, सदस्य के कॉन्फ़िगरेशन को नई endpointAuthorization वैल्यू के साथ अपडेट करें.
  3. अपने एंडपॉइंट को कॉन्फ़िगर करें, ताकि वह दूसरे चरण के पूरा होने की पुष्टि के बाद सिर्फ़ नई endpointAuthorization वैल्यू स्वीकार करे.

उपयोगकर्ता की सदस्यताएं

Google Health API की मदद से, उपयोगकर्ताओं की सदस्यताओं को बेहतर तरीके से मैनेज किया जा सकता है. इससे उपयोगकर्ता के ऑनबोर्डिंग के दौरान, मैन्युअल रजिस्ट्रेशन की ज़रूरत कम हो जाती है.

अपने-आप रिन्यू होने वाली सदस्यताएं

हमारा सुझाव है कि ऑटोमैटिक सदस्यताएं इस्तेमाल करें. इस सुविधा को चालू करने के लिए, subscriberConfigs में जाकर, खास डेटा टाइप के लिए subscriptionCreatePolicy को AUTOMATIC पर सेट करें. dataTypes नीति के तहत बताए गए AUTOMATIC, उसी तरह के डेटा टाइप होते हैं जिनके लिए Google Health API सूचनाएं भेजता है. हालांकि, इसके लिए यह ज़रूरी है कि उपयोगकर्ता ने उन डेटा टाइप के लिए भी सहमति दी हो.

जब कोई उपयोगकर्ता, AUTOMATIC नीति वाले डेटा टाइप से जुड़े स्कोप के लिए ऐप्लिकेशन को सहमति देता है, तो Google Health API अपने-आप उन डेटा टाइप को ट्रैक करता है जिनके लिए उपयोगकर्ता ने सहमति दी है. साथ ही, उन डेटा टाइप के लिए सूचनाएं भेजता है. ये डेटा टाइप, उपयोगकर्ता की सहमति वाले डेटा टाइप और उस उपयोगकर्ता के लिए अपने-आप कॉन्फ़िगर होने वाले सदस्य के डेटा टाइप के इंटरसेक्शन से मिलते हैं. इसके बाद, जब भी वह उपयोगकर्ता उन टाइप के लिए नया डेटा जनरेट करता है, तब आपके एंडपॉइंट को सूचनाएं भेजी जाती हैं. यह उन उपयोगकर्ताओं के लिए काम करता है जिन्होंने सदस्य बनाने से पहले या बाद में सहमति दी है. सदस्यता लेने वाले व्यक्ति के खाते के बनने से पहले जनरेट किए गए डेटा के लिए, सूचनाएं बैकफ़िल नहीं की जाती हैं.

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

मैन्युअल सदस्यताएं

अगर आपके सदस्य ने कुछ खास तरह के डेटा के लिए, मैन्युअल subscription_create_policy कॉन्फ़िगरेशन चुना है, तो आपको हर उपयोगकर्ता के लिए सदस्यताएं बनानी और मैनेज करनी होंगी. सदस्यता, किसी उपयोगकर्ता को आपके सदस्य एंडपॉइंट से लिंक करती है. ऐसा डेटा टाइप के तय किए गए सेट के लिए किया जाता है. डेवलपर, इन कामों के लिए खास एपीआई का इस्तेमाल कर सकते हैं:

  • हर healthUserId के लिए सदस्यताएं (मैन्युअल तरीके से) बनाएं - इससे किसी उपयोगकर्ता के लिए नई सदस्यता बनती है. इस तरीके के लिए, ज़रूरी है कि अनुरोध करने वाले व्यक्ति के पास, अनुरोध किए गए डेटा टाइप के लिए SubscriptionCreatePolicy की वैल्यू MANUAL पर सेट हो.
  • सदस्यता अपडेट करना (मैन्युअल) - इससे किसी मौजूदा उपयोगकर्ता की सदस्यता के डेटा टाइप अपडेट किए जाते हैं.
  • सदस्यता मिटाएं (मैन्युअल) - इससे किसी उपयोगकर्ता की सदस्यता मिट जाती है. मिटाए जाने के बाद, आपके सदस्य के एंडपॉइंट को इस उपयोगकर्ता के लिए, इससे जुड़े डेटा टाइप की सूचनाएं नहीं मिलेंगी.
  • सदस्यता (मैन्युअल) की सूची - इससे किसी सदस्य की सभी चालू सदस्यताओं की सूची मिलती है. नतीजों को उपयोगकर्ता या डेटा टाइप के हिसाब से फ़िल्टर किया जा सकता है.

सूचनाएं

जब किसी उपयोगकर्ता का डेटा, सदस्यता लिए गए डेटा टाइप के लिए बदलता है, तो Google Health API, सदस्य के एंडपॉइंट यूआरएल पर एचटीटीपीएस पोस्ट अनुरोध भेजता है.

सूचना का फ़ॉर्मैट

सूचना का पेलोड एक JSON ऑब्जेक्ट होता है. इसमें डेटा में हुए बदलावों के बारे में जानकारी होती है. इसमें उपयोगकर्ता आईडी, डेटा टाइप, और समय अंतराल शामिल होते हैं. इनका इस्तेमाल करके, अपडेट किए गए डेटा के बारे में क्वेरी की जा सकती है.

{
  "data": {
    "version": "1",
    "clientProvidedSubscriptionName": "subscription-name",
    "healthUserId": "health-user-id",
    "operation": "UPSERT",
    "dataType": "steps",
    "intervals": [
      {
        "physicalTimeInterval": {
          "startTime": "2026-03-08T01:29:00Z",
          "endTime": "2026-03-08T01:34:00Z"
        },
        "civilDateTimeInterval": {
          "startDateTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 7
            },
            "time": {
              "hours": 17,
              "minutes": 29
            }
          },
          "endDateTime": {
            "date": {
              "year": 2026,
              "month": 3,
              "day": 7
            },
            "time": {
              "hours": 17,
              "minutes": 34
            }
          }
        },
        "civilIso8601TimeInterval": {
          "startTime": "2026-03-07T17:29:00",
          "endTime": "2026-03-07T17:34:00"
        }
      }
    ]
  }
}

operation फ़ील्ड से पता चलता है कि किस तरह के बदलाव की वजह से सूचना ट्रिगर हुई है:

  • UPSERT: यह सूचना, डेटा में कोई भी बदलाव करने या डेटा जोड़ने के लिए भेजी जाती है.
  • DELETE: यह तब भेजा जाता है, जब कोई उपयोगकर्ता डेटा मिटाता है.

हमारा सुझाव है कि सूचनाएं मैनेज करने के लिए, लॉजिक को आइडेमपोटेंट बनाएं. खास तौर पर, UPSERT कार्रवाइयों के लिए. ऐसा इसलिए, क्योंकि फिर से कोशिश करने पर डुप्लीकेट सूचनाएं भेजी जा सकती हैं.

clientProvidedSubscriptionName फ़ील्ड एक यूनीक आइडेंटिफ़ायर है. MANUAL नीति के तहत आने वाली सदस्यताओं के लिए, इस फ़ील्ड में सदस्यता का वह नाम होता है जिसे डेवलपर ने सदस्यता बनाते समय बताया था. यह नाम हमेशा दिखता है. इससे मैन्युअल सदस्यताएं मैनेज करने के लिए एक स्टेबल आईडी मिलता है. AUTOMATIC नीति के तहत बनाई गई सदस्यताओं के लिए, Google Health API इस फ़ील्ड में हर सूचना के लिए एक यूनीक आइडेंटिफ़ायर (रैंडम यूयूआईडी) अपने-आप जनरेट करता है और असाइन करता है. मैन्युअल और ऑटोमैटिक, दोनों तरह की नीतियों के लिए clientProvidedSubscriptionName शामिल करने से, सभी तरह की सदस्यताओं के लिए सूचना पेलोड का फ़ॉर्मैट एक जैसा होता है.

healthUserId, Google Health API का एक आइडेंटिफ़ायर है. यह उस उपयोगकर्ता के लिए होता है जिसका डेटा बदला गया है. अगर आपका ऐप्लिकेशन एक से ज़्यादा लोगों के लिए उपलब्ध है, तो आपको उन सभी लोगों के लिए सूचनाएं मिल सकती हैं जिन्होंने आपके ऐप्लिकेशन को सहमति दी है. जब आपको सूचना मिलती है, तो healthUserId का इस्तेमाल करके यह पता लगाएं कि किस उपयोगकर्ता के डेटा में बदलाव हुआ है. इससे आपको उनके डेटा को क्वेरी करने के लिए, उनके OAuth क्रेडेंशियल का इस्तेमाल करने में मदद मिलेगी.

किसी उपयोगकर्ता के OAuth क्रेडेंशियल को उसके healthUserId से मैप करने के लिए, getIdentity एंडपॉइंट का इस्तेमाल करें. उपयोगकर्ता के ऑनबोर्डिंग के दौरान, उपयोगकर्ता के क्रेडेंशियल के साथ इस एंडपॉइंट को कॉल करें, ताकि उसके healthUserId को वापस पाया जा सके. साथ ही, इस मैपिंग को सेव करें. यह मैपिंग समय के साथ नहीं बदलती है. इसलिए, इसे अनिश्चित काल के लिए कैश मेमोरी में सेव किया जा सकता है. उदाहरण के लिए, यूज़र आईडी पाना लेख देखें. इससे आपको सूचना में मौजूद healthUserId के आधार पर डेटा क्वेरी करते समय, उपयोगकर्ता के सही क्रेडेंशियल चुनने में मदद मिलती है.

अपडेट को इकट्ठा करना

नेटवर्क ट्रैफ़िक को कम करने के लिए, Google Health API मैसेज को एक साथ बैच करता है. सिस्टम को इस तरह कॉन्फ़िगर किया गया है कि वह हर बैच में ज़्यादा से ज़्यादा 99 मैसेज भेज सकता है. ये मैसेज उपलब्ध होते ही अपने-आप भेज दिए जाते हैं.

किसी सूचना का जवाब देना

आपके सर्वर को सूचनाओं का जवाब, एचटीटीपी 204 No Content स्टेटस कोड के साथ तुरंत देना होगा. टाइमआउट से बचने के लिए, जवाब भेजने के बाद सूचना के पेलोड को एसिंक्रोनस तरीके से प्रोसेस करें. अगर Google Health API को कोई दूसरा स्टेटस कोड मिलता है या अनुरोध का समय खत्म हो जाता है, तो वह बाद में सूचना भेजने की कोशिश करता है.

Node.js (Express) का उदाहरण:

app.post('/webhook-receiver', (req, res) => {
    // 1. Immediately acknowledge the notification
    res.status(204).send();

    // 2. Process the data asynchronously in the background
    const notification = req.body;
    setImmediate(() => {
        console.log(`Update for user ${notification.data.healthUserId} of type ${notification.data.dataType}`);
        // Trigger your data retrieval logic here
    });
});

डेटा में बदलाव होने की सूचना मिलने के बाद, डेटाबेस को अपडेट करने के लिए तीन सामान्य रणनीतियां हैं:

  • लाइन में लगाना (सुझाया गया): आने वाली सूचनाओं को मैसेज की लाइन में लगाएं और सिस्टम के संसाधनों के आधार पर, उन्हें लाइन से हटाकर प्रोसेस करें.
  • तुरंत डेटा पाना: अपने बैकएंड को Google Health API को तुरंत कॉल करने के लिए कहें, ताकि अपडेट किया गया डेटा फ़ेच किया जा सके और उसे आपके डेटाबेस में सेव किया जा सके.
  • लेज़ी अपडेट: उपयोगकर्ता के लोकल डेटाबेस के रिकॉर्ड को डर्टी के तौर पर मार्क करें. साथ ही, जब उपयोगकर्ता अगली बार आपके ऐप्लिकेशन पर जाए, तब Google Health API से सिर्फ़ अपडेट किया गया डेटा फ़ेच करें.

क्यूइंग की रणनीति की मदद से, डेटा को करीब-करीब रीयल-टाइम में प्रोसेस किया जा सकता है. साथ ही, सूचनाओं की बाढ़ से बचा जा सकता है. उदाहरण के लिए, अगर सेवा बंद होने की वजह से, सूचनाओं का बैकलॉग एक साथ डिलीवर हो जाता है. आपके पास इन कतारों को लंबे समय के अंतराल वाले बैच शेड्यूल (उदाहरण के लिए, हर तीन घंटे में) पर प्रोसेस करने का विकल्प होता है, ताकि संसाधनों को बचाया जा सके. हालांकि, इसकी एक कमी यह है कि उपयोगकर्ता आम तौर पर यह उम्मीद करते हैं कि उनका डेटा लगभग रीयल-टाइम में अपडेट हो जाए.

सबसे सही तरीके

डेटा अपडेट को भरोसेमंद और असरदार तरीके से मैनेज करने के लिए, इन सबसे सही तरीकों को अपनाएं:

  • Subscription API का इस्तेमाल करें: Subscription API का इस्तेमाल करके, यह सूचना पाएं कि किसी उपयोगकर्ता के पास डाउनलोड करने के लिए नया डेटा है. इसके लिए, पोलिंग एंडपॉइंट का इस्तेमाल न करें.
  • सूचनाओं को अलग-अलग करके प्रोसेस करें और उन्हें एक क्रम में लगाएं: सदस्यता से जुड़ी सूचनाएं मिलने पर, उन्हें एक क्रम में लगाएं और अपने सिस्टम के संसाधनों के आधार पर उन्हें अलग-अलग करके प्रोसेस करें. अनुरोध को तुरंत स्वीकार करके, वेबुक एंडपॉइंट को हल्का रखें.

हस्ताक्षर की पुष्टि करना

वेबहुक सूचनाओं की पुष्टि करने के लिए, हर आउटगोइंग वेबहुक सूचना के रॉ JSON पेलोड पर, निजी कुंजी का इस्तेमाल करके हस्ताक्षर किया जाता है. इसके लिए, Tink के PublicKeySign का इस्तेमाल किया जाता है. साथ ही, अनुरोध में GOOGLE-HEALTH-API-SIGNATURE एचटीटीपी हेडर में Base64-एन्कोड किया गया हस्ताक्षर दिया जाता है. हस्ताक्षर करने वाली इन कुंजियों को हर 30 दिनों में अपने-आप रोटेट किया जाता है. साथ ही, इससे जुड़ा आधिकारिक पब्लिक कीसेट, JSON फ़ाइल के तौर पर इस स्थायी यूआरएल पर डिस्ट्रिब्यूट किया जाता है: https://www.gstatic.com/googlehealthapi/webhooks/webhooks_public_keyset.json.

हस्ताक्षर की पुष्टि करने का तरीका

Tink का इस्तेमाल करना (सुझाया गया): डेवलपर, Tink के PublicKeyVerify प्रिमिटिव का इस्तेमाल करके हस्ताक्षर की पुष्टि कर सकते हैं. स्थायी यूआरएल से सार्वजनिक कीसेट फ़ेच करें, कीसेट के साथ PublicKeyVerify प्रिमिटिव को इंस्टैंशिएट करें, और डिकोड किए गए GOOGLE-HEALTH-API-SIGNATURE हेडर की पुष्टि, रॉ वेबहुक JSON पेलोड के ख़िलाफ़ करें.

मैन्युअल तरीके से पुष्टि करना (Tink के बिना): अगर डेवलपर Tink का इस्तेमाल नहीं करना चाहते हैं, तो वे मैन्युअल तरीके से हस्ताक्षर की पुष्टि कर सकते हैं. इसके लिए, यह तरीका अपनाएं:

  1. यह फ़ंक्शन, GOOGLE-HEALTH-API-SIGNATURE हेडर को Base64 से डिकोड करता है, ताकि 5 बाइट वाले Tink प्रीफ़िक्स (जिसमें 1 बाइट वाला वर्शन प्रीफ़िक्स और 4 बाइट वाला keyId होता है) को DER-एन्कोड किए गए असली हस्ताक्षर से अलग किया जा सके.
  2. https://www.gstatic.com/googlehealthapi/webhooks/webhooks_public_keyset.json से JSON कीसेट फ़ेच करें.
  3. पार्स किए गए keyId से मेल खाने वाली कुंजी ढूंढें और उसके वैल्यू फ़ील्ड को Base64-डिकोड करें. इसमें क्रम से लगाया गया EcdsaPublicKey प्रोटोकॉल बफ़र होता है.
  4. इस बाइनरी पेलोड से, बिग-एंडियन x और y कोऑर्डिनेट (Protobuf टैग 3 और 4) निकालें.
  5. एक्सट्रैक्ट किए गए x और y कोऑर्डिनेट का इस्तेमाल करके, क्रिप्टोग्राफ़ी की बिल्ट-इन लाइब्रेरी में स्टैंडर्ड ECDSA P-256 सार्वजनिक कुंजी को इंस्टैंटिएट करें.
  6. SHA-256 एल्गोरिदम का इस्तेमाल करके, निकाले गए DER सिग्नेचर के हिसाब से, रॉ वेबहुक JSON पेलोड की पुष्टि करें.

सदस्यता की स्थिति और उसे वापस पाने का तरीका

अगर आपका सदस्य एंडपॉइंट उपलब्ध नहीं होता है या गड़बड़ी वाला स्टेटस कोड (204 के अलावा कोई और कोड) दिखाता है, तो Google Health API, सात दिनों तक सूचनाएं सेव करता है. साथ ही, वह एक्सपोनेंशियल बैकऑफ़ के साथ सूचनाएं डिलीवर करने की कोशिश करता है.

आपका एंडपॉइंट फिर से ऑनलाइन होने और 204 के साथ जवाब देने पर, एपीआई स्टोर किए गए मैसेज का बैकलॉग अपने-आप डिलीवर कर देता है. सात दिन से ज़्यादा पुरानी सूचनाएं हटा दी जाती हैं और उन्हें वापस नहीं लाया जा सकता.

आम तौर पर होने वाली गड़बड़ियां

गड़बड़ी का कोड मैसेज ब्यौरा सुझाव
400 खराब अनुरोध संसाधन के नाम में मौजूद प्रोजेक्ट नंबर अमान्य है जब प्रोजेक्ट नंबर के बजाय, अनुरोध यूआरएल में Google Cloud प्रोजेक्ट आईडी का इस्तेमाल करके किसी सदस्य को मिटाया या अपडेट किया जाता है. यह projects.subscribers एंडपॉइंट का इस्तेमाल करके, वेबुक की सदस्यताओं पर लागू होता है. अनुरोध यूआरएल में, अपने Google Cloud प्रोजेक्ट नंबर का इस्तेमाल करें, न कि प्रोजेक्ट आईडी का.
403 निषिद्ध कॉलर के पास अनुमति नहीं है जब प्रोजेक्ट नंबर के बजाय, अनुरोध यूआरएल में Google Cloud प्रोजेक्ट आईडी का इस्तेमाल करके सदस्य बनाए या उनकी सूची बनाई जाती है. यह projects.subscribers एंडपॉइंट का इस्तेमाल करके, वेबुक की सदस्यताओं पर लागू होता है. अनुरोध यूआरएल में, अपने Google Cloud प्रोजेक्ट नंबर का इस्तेमाल करें, न कि प्रोजेक्ट आईडी का.

पीछे जाएं
यूनिवर्सल लिंक और ऐप्लिकेशन लिंक
आगे बढ़ें
समस्या का हल