बैच अनुरोध भेजें

इस दस्तावेज़ में, एपीआई कॉल को एक साथ बैच में भेजने का तरीका बताया गया है. इससे क्लाइंट के बनाए जाने वाले एचटीटीपी कनेक्शन कम हो जाते हैं.

यह दस्तावेज़, खास तौर पर एचटीटीपी अनुरोध भेजकर बैच अनुरोध करने के बारे में है. अगर बैच अनुरोध करने के लिए, Google की क्लाइंट लाइब्रेरी का इस्तेमाल किया जा रहा है, तो क्लाइंट लाइब्रेरी का दस्तावेज़ देखें.

खास जानकारी

क्लाइंट के हर एचटीटीपी कनेक्शन से कुछ हद तक ओवरहेड होता है. Google Ad Experience Report API में बैचिंग की सुविधा काम करती है. इससे आपका क्लाइंट, कई एपीआई कॉल को एक एचटीटीपी अनुरोध में शामिल कर सकता है.

बैचिंग का इस्तेमाल करने की स्थितियों के उदाहरण:

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

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

एक बैच अनुरोध में ज़्यादा से ज़्यादा 1,000 कॉल किए जा सकते हैं. अगर आपको इससे ज़्यादा कॉल करने हैं, तो एक से ज़्यादा बैच अनुरोधों का इस्तेमाल करें.

ध्यान दें: Google Ad Experience Report API के बैच सिस्टम में, OData बैच प्रोसेसिंग सिस्टम के जैसा ही सिंटैक्स इस्तेमाल किया जाता है. हालांकि, सिमैंटिक अलग-अलग होते हैं.

बैच की जानकारी

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

ध्यान दें: एक साथ बैच किए गए n अनुरोधों के सेट को, इस्तेमाल की सीमा में n अनुरोधों के तौर पर गिना जाता है, न कि एक अनुरोध के तौर पर. बैच में भेजे गए अनुरोध को प्रोसेस करने से पहले, अनुरोधों के सेट में अलग किया जाता है.

एक साथ ग्रुप या बैच में भेजे गए अनुरोध का फ़ॉर्मैट

बैच अनुरोध, एक स्टैंडर्ड एचटीटीपी अनुरोध होता है. इसमें multipart/mixed कॉन्टेंट टाइप का इस्तेमाल करके, Google Ad Experience Report API के कई कॉल शामिल होते हैं. मुख्य एचटीटीपी अनुरोध में, हर हिस्से में नेस्ट किया गया एचटीटीपी अनुरोध होता है.

हर हिस्से की शुरुआत, उसके Content-Type: application/http एचटीटीपी हेडर से होती है. इसमें Content-ID हेडर भी हो सकता है. हालांकि, ऐसा करना ज़रूरी नहीं है. हालांकि, पार्ट हेडर सिर्फ़ पार्ट की शुरुआत को मार्क करने के लिए होते हैं. ये नेस्ट किए गए अनुरोध से अलग होते हैं. सर्वर, बैच अनुरोध को अलग-अलग अनुरोधों में बदलने के बाद, पार्ट हेडर को अनदेखा कर देता है.

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

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

उदाहरण के लिए, अगर आपने किसी कॉल के लिए Authorization हेडर दिया है, तो वह हेडर सिर्फ़ उस कॉल पर लागू होगा. अगर आपने बाहरी अनुरोध के लिए Authorization हेडर दिया है, तो वह हेडर सभी अलग-अलग कॉल पर लागू होता है. हालांकि, ऐसा तब तक होता है, जब तक वे अपने Authorization हेडर से इसे बदल नहीं देते.

जब सर्वर को बैच किया गया अनुरोध मिलता है, तो वह बाहरी अनुरोध के क्वेरी पैरामीटर और हेडर (ज़रूरत के मुताबिक) को हर हिस्से पर लागू करता है. इसके बाद, हर हिस्से को इस तरह से प्रोसेस करता है जैसे वह एक अलग एचटीटीपी अनुरोध हो.

बैच अनुरोध का जवाब

सर्वर का जवाब, multipart/mixed कॉन्टेंट टाइप वाला एक स्टैंडर्ड एचटीटीपी रिस्पॉन्स होता है. हर हिस्सा, बैच किए गए अनुरोध में शामिल किसी एक अनुरोध का जवाब होता है. यह जवाब, अनुरोधों के क्रम में ही होता है.

अनुरोध के हिस्सों की तरह, जवाब के हर हिस्से में एक पूरा एचटीटीपी जवाब होता है. इसमें स्टेटस कोड, हेडर, और कोड शामिल होता है. अनुरोध में शामिल हिस्सों की तरह, जवाब के हर हिस्से से पहले Content-Type हेडर होता है. इससे हिस्से की शुरुआत का पता चलता है.

अगर अनुरोध के किसी हिस्से में Content-ID हेडर मौजूद है, तो रिस्पॉन्स के उस हिस्से में भी Content-ID हेडर मौजूद होगा. इसमें ओरिजनल वैल्यू से पहले response- स्ट्रिंग मौजूद होगी. इसे यहां दिए गए उदाहरण में दिखाया गया है.

ध्यान दें: सर्वर, आपके कॉल किसी भी क्रम में कर सकता है. यह ज़रूरी नहीं है कि उन्हें उसी क्रम में लागू किया जाए जिस क्रम में आपने उन्हें तय किया है. अगर आपको यह पक्का करना है कि दो कॉल एक तय क्रम में हों, तो उन्हें एक ही अनुरोध में नहीं भेजा जा सकता. इसके बजाय, पहले कॉल को अलग से भेजें. इसके बाद, दूसरे कॉल को भेजने से पहले, पहले कॉल के जवाब का इंतज़ार करें.

उदाहरण

यहां दिए गए उदाहरण में, Google Ad Experience Report API के साथ बैचिंग का इस्तेमाल दिखाया गया है.

एक साथ ग्रुप या बैच में भेजे गए अनुरोध का उदाहरण

  POST /batch/v1?key=key HTTP/1.1
  Content-Type: multipart/mixed; boundary=batch_aer

  --batch_aer
  Content-Type: application/http
  Content-ID: id1

  GET /v1/sites/http%3A%2F%2F/site1%2F HTTP/1.1

  --batch_aer
  Content-Type: application/http
  Content-ID: id2

  GET /v1/sites/http%3A%2F%2F/site2%2F HTTP/1.1

  --batch_aer--
  

बैच रिस्पॉन्स का उदाहरण

यह पिछले सेक्शन में दिए गए उदाहरण के अनुरोध का जवाब है.

  HTTP/1.1 200 OK
  Content-Type: multipart/mixed; boundary=batch_aer

  --batch_aer
  Content-Type: application/http
  Content-ID: response-id1

  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "reviewedSite": "site1",
    "mobileSummary": {
      "lastChangeTime": "2019-02-05T09:46:26.521747Z",
      "betterAdsStatus": "PASSING",
      "reportUrl": "https://www.google.com/webmasters/tools/ad-experience-mobile?siteUrl=http://site1/",
      "filterStatus": "OFF"
    },
    "desktopSummary": {
      "lastChangeTime": "2019-02-07T23:07:29.017206Z",
      "betterAdsStatus": "FAILING",
      "enforcementTime": "2018-02-15T15:00:00Z",
      "reportUrl": "https://www.google.com/webmasters/tools/ad-experience-desktop?siteUrl=http://site1/",
      "filterStatus": "ON"
    }
  }

  --batch_aer
  Content-Type: application/http
  Content-ID: response-id2

  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "reviewedSite": "site2",
    "mobileSummary": {
      "lastChangeTime": "2018-03-06T16:06:33.375851Z",
      "betterAdsStatus": "PASSING",
      "reportUrl": "https://www.google.com/webmasters/tools/ad-experience-mobile?siteUrl=http://site2/",
      "filterStatus": "OFF"
    },
    "desktopSummary": {
      "lastChangeTime": "2018-03-06T16:06:33.375851Z",
      "betterAdsStatus": "PASSING",
      "reportUrl": "https://www.google.com/webmasters/tools/ad-experience-desktop?siteUrl=http://site2/",
      "filterStatus": "OFF"
    }
  }

  --batch_aer--