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

बैच में, एचटीटीपी एचटीटीपी बैच एंडपॉइंट (www.googleapis.com/batch) लॉन्च करने का एक खास तरीका 12 अगस्त, 2020 को बंद कर दिया गया. इसके बारे में Google Developers ब्लॉग पर बताया गया था. बैच में काम करने के दूसरे तरीके अब भी काम करते हैं, जैसा कि इस पेज के बाकी हिस्से में बताया गया है. अगर आपका कोड ग्लोबल एचटीटीपी बैच एंडपॉइंट का इस्तेमाल करता है, तो ट्रांज़िशन के बारे में निर्देशों के लिए ब्लॉग पोस्ट देखें. इसमें एपीआई से जुड़े एचटीटीपी बैच एंडपॉइंट (www.googleapis.com/batch/API/VERSION) जैसे दूसरे तरीकों का इस्तेमाल किया जा सकता है.

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

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

खास जानकारी

आपके क्लाइंट का हर एचटीटीपी कनेक्शन, एक तय संख्या में ओवरहेड बनाता है. Google विज्ञापन अनुभव रिपोर्ट API (एपीआई) बैच के साथ काम करता है, ताकि आपके क्लाइंट कई एपीआई कॉल को एक ही एचटीटीपी अनुरोध में शामिल कर सकें.

ऐसी स्थितियों के उदाहरण जिनमें आपको बैच में इस्तेमाल करना पड़ सकता है:

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

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

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

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

बैच के विवरण

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

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

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

बैच अनुरोध एक स्टैंडर्ड एचटीटीपी अनुरोध होता है. इसमें multipart/mixed कॉन्टेंट टाइप का इस्तेमाल करके, Google विज्ञापन अनुभव रिपोर्ट के कई एपीआई कॉल होते हैं. उस मुख्य एचटीटीपी अनुरोध में, हर हिस्से में एक नेस्ट किया हुआ एचटीटीपी अनुरोध होता है.

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

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

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

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

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

बैच में भेजे गए अनुरोध का जवाब

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

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

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

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

उदाहरण

इस उदाहरण में, Google विज्ञापन अनुभव रिपोर्ट एपीआई के साथ बैच बनाने की सुविधा के इस्तेमाल के बारे में बताया गया है.

बैच अनुरोध का उदाहरण

  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--