इस दस्तावेज़ में, एपीआई कॉल को एक साथ बैच करने का तरीका बताया गया है. इससे आपके क्लाइंट को बनाने वाले एचटीटीपी कनेक्शन की संख्या कम हो जाती है.
इस दस्तावेज़ में खास तौर पर, एचटीटीपी अनुरोध भेजकर बैच में अनुरोध करने के बारे में बताया गया है. अगर बैच रिक्वेस्ट करने के लिए, Google की क्लाइंट लाइब्रेरी का इस्तेमाल किया जा रहा है, तो क्लाइंट लाइब्रेरी का दस्तावेज़ देखें.
खास जानकारी
आपके क्लाइंट के हर एचटीटीपी कनेक्शन से कुछ ओवरहेड होता है. Google Classroom API, एक साथ कई अनुरोध भेजने की सुविधा देता है. इससे आपके क्लाइंट को एक ही एचटीटीपी अनुरोध में कई एपीआई कॉल डालने की अनुमति मिलती है.
उन स्थितियों के उदाहरण, जब आपको एक साथ कई बैच बनाने की सुविधा इस्तेमाल करनी चाहिए:
- बड़ी संख्या में कोर्स के लिए रोस्टर हासिल करना.
- एक साथ कई कोर्स बनाना या अपडेट करना.
- बड़ी संख्या में कोर्स की नामावलियों को जोड़ा जा रहा है.
- बड़ी संख्या में उपयोगकर्ताओं के लिए कोर्स की सूचियां हासिल करना.
हर मामले में, हर कॉल को अलग से भेजने के बजाय, उन्हें एक ही एचटीटीपी अनुरोध में ग्रुप किया जा सकता है. सभी इनर अनुरोध, एक ही Google API को भेजे जाने चाहिए.
एक साथ 50 कॉल किए जा सकते हैं. अगर आपको इससे ज़्यादा कॉल करने हैं, तो एक से ज़्यादा बैच रिक्वेस्ट का इस्तेमाल करें.
ध्यान दें: Google Classroom API के लिए बॅच सिस्टम, OData बॅच प्रोसेसिंग सिस्टम के जैसे ही सिंटैक्स का इस्तेमाल करता है. हालांकि, इनमें सेमेटिक्स अलग-अलग होते हैं.
बैच की जानकारी
बैच रिक्वेस्ट में एक एचटीटीपी रिक्वेस्ट में कई एपीआई कॉल शामिल होते हैं. इसे एपीआई डिस्कवरी दस्तावेज़ में बताए गए batchPath
पर भेजा जा सकता है. डिफ़ॉल्ट पाथ /batch/api_name/api_version
है. इस सेक्शन में, बैच सिंटैक्स के बारे में पूरी जानकारी दी गई है. इसके बाद, एक उदाहरण दिया गया है.
ध्यान दें: एक साथ किए गए n अनुरोधों के सेट को, इस्तेमाल की सीमा में एक अनुरोध के तौर पर नहीं, बल्कि n अनुरोधों के तौर पर गिना जाता है. बैच में किए गए अनुरोधों को प्रोसेस करने से पहले, उन्हें अनुरोधों के सेट में बांट दिया जाता है.
एक साथ कई अनुरोध करने का फ़ॉर्मैट
बैच रिक्वेस्ट, एक स्टैंडर्ड एचटीटीपी रिक्वेस्ट होता है. इसमें multipart/mixed
कॉन्टेंट टाइप का इस्तेमाल करके, Google Classroom के कई एपीआई कॉल शामिल होते हैं. उस मुख्य एचटीटीपी अनुरोध में, हर हिस्से में नेस्ट किया गया एचटीटीपी अनुरोध होता है.
हर हिस्सा अपने Content-Type: application/http
एचटीटीपी हेडर से शुरू होता है. इसमें एक वैकल्पिक Content-ID
हेडर भी हो सकता है. हालांकि, पार्ट हेडर सिर्फ़ पार्ट की शुरुआत को मार्क करने के लिए होते हैं. ये नेस्ट किए गए अनुरोध से अलग होते हैं. जब सर्वर, बैच रिक्वेस्ट को अलग-अलग रिक्वेस्ट में अनरैप कर देता है, तो पार्ट हेडर को अनदेखा कर दिया जाता है.
हर हिस्से का मुख्य हिस्सा एक पूरा एचटीटीपी अनुरोध होता है. इसमें अपना वर्ब, यूआरएल, हेडर, और कोड होता है. एचटीटीपी अनुरोध में सिर्फ़ यूआरएल का पाथ हिस्सा शामिल होना चाहिए. एक साथ कई अनुरोधों में पूरे यूआरएल शामिल करने की अनुमति नहीं है.
बाहरी बैच अनुरोध के लिए एचटीटीपी हेडर, बैच में मौजूद हर अनुरोध पर लागू होते हैं. हालांकि, Content-Type
जैसे Content-
हेडर पर ये लागू नहीं होते. अगर किसी दिए गए एचटीटीपी हेडर को आउटर रिक्वेस्ट और किसी कॉल, दोनों में तय किया जाता है, तो अलग-अलग कॉल हेडर की वैल्यू, आउटर बैच रिक्वेस्ट हेडर की वैल्यू को बदल देती है. किसी कॉल के लिए सेट किए गए हेडर, सिर्फ़ उस कॉल पर लागू होते हैं.
उदाहरण के लिए, अगर आपने किसी खास कॉल के लिए अनुमति वाला हेडर दिया है, तो वह हेडर सिर्फ़ उस कॉल पर लागू होगा. अगर बाहरी अनुरोध के लिए अनुमति हेडर दिया जाता है, तो वह हेडर सभी अलग-अलग कॉल पर लागू होता है. ऐसा तब तक होता है, जब तक वे अपने अनुमति हेडर से उसे बदल नहीं देते.
जब सर्वर को एक साथ कई अनुरोध मिलते हैं, तो वह हर हिस्से पर बाहरी अनुरोध के क्वेरी पैरामीटर और हेडर (जैसा कि ज़रूरी हो) लागू करता है. इसके बाद, हर हिस्से को एक अलग एचटीटीपी अनुरोध के तौर पर इस्तेमाल करता है.
बैच में भेजे गए अनुरोध का जवाब
सर्वर का रिस्पॉन्स, एक स्टैंडर्ड एचटीटीपी रिस्पॉन्स है जिसमें multipart/mixed
कॉन्टेंट टाइप होता है. हर हिस्सा, बैच किए गए अनुरोध में किसी एक अनुरोध का रिस्पॉन्स होता है. यह रिस्पॉन्स, अनुरोधों के क्रम में ही होता है.
अनुरोध के हिस्सों की तरह ही, जवाब के हर हिस्से में एक पूरा एचटीटीपी जवाब होता है. इसमें स्टेटस कोड, हेडर, और मुख्य हिस्सा शामिल होता है. अनुरोध के हिस्सों की तरह ही, जवाब के हर हिस्से के पहले एक Content-Type
हेडर होता है, जो हिस्से की शुरुआत को मार्क करता है.
अगर अनुरोध के किसी हिस्से में Content-ID
हेडर था, तो रिस्पॉन्स के उस हिस्से में मैच करने वाला Content-ID
हेडर होगा. साथ ही, ओरिजनल वैल्यू के आगे स्ट्रिंग response-
होगी, जैसा कि नीचे दिए गए उदाहरण में दिखाया गया है.
ध्यान दें: सर्वर आपके कॉल को किसी भी क्रम में कर सकता है. यह उम्मीद न करें कि वे उसी क्रम में लागू होंगे जिस क्रम में आपने उन्हें तय किया है. अगर आपको यह पक्का करना है कि दो कॉल किसी तय क्रम में हों, तो उन्हें एक ही अनुरोध में नहीं भेजा जा सकता. इसके बजाय, पहले कॉल को अलग से भेजें. इसके बाद, दूसरे कॉल को भेजने से पहले, पहले कॉल के जवाब का इंतज़ार करें.
उदाहरण
यहां दिए गए उदाहरण में, Google Classroom API के साथ एक साथ कई अनुरोध करने की सुविधा का इस्तेमाल दिखाया गया है.
एक साथ कई अनुरोध करने का उदाहरण
POST https://classroom.googleapis.com/batch HTTP/1.1 Authorization: Bearer your_auth_token Content-Type: multipart/mixed; boundary=batch_foobarbaz Content-Length: total_content_length --batch_foobarbaz Content-Type: application/http Content-Transfer-Encoding: binary MIME-Version: 1.0 Content-ID: <item1:12930812@classroom.example.com> PATCH /v1/courses/134529639?updateMask=name HTTP/1.1 Content-Type: application/json; charset=UTF-8 Authorization: Bearer your_auth_token { "name": "Course 1" } --batch_foobarbaz Content-Type: application/http Content-Transfer-Encoding: binary MIME-Version: 1.0 Content-ID: <item2:12930812@classroom.example.com> PATCH /v1/courses/134529901?updateMask=section HTTP/1.1 Content-Type: application/json; charset=UTF-8 Authorization: Bearer your_auth_token { "section": "Section 2" } --batch_foobarbaz--
एक साथ कई अनुरोधों के जवाब का उदाहरण
यह पिछले सेक्शन में उदाहरण के तौर पर किए गए अनुरोध का जवाब है.
HTTP/1.1 200 Content-Length: response_total_content_length Content-Type: multipart/mixed; boundary=batch_foobarbaz --batch_foobarbaz Content-Type: application/http Content-ID: <response-item1:12930812@classroom.example.com> HTTP/1.1 200 OK Content-Type application/json Content-Length: response_part_1_content_length { "id": "134529639", "name": "Course 1", "section": "Section 1", "ownerId": "116269102540619633451", "creationTime": "2015-06-25T14:23:56.535Z", "updateTime": "2015-06-25T14:33:06.583Z", "enrollmentCode": "6paeflo", "courseState": "PROVISIONED", "alternateLink": "http://classroom.google.com/c/MTM0NTI5NjM5" } --batch_foobarbaz Content-Type: application/http Content-ID: <response-item2:12930812@classroom.example.com> HTTP/1.1 200 OK Content-Type: application/json Content-Length: response_part_2_content_length { "id": "134529901", "name": "Course 1", "section": "Section 2", "ownerId": "116269102540619633451", "creationTime": "2015-06-25T14:23:08.761Z", "updateTime": "2015-06-25T14:33:06.490Z", "enrollmentCode": "so75ha5", "courseState": "PROVISIONED", "alternateLink": "http://classroom.google.com/c/MTM0NTI5OTAx" } --batch_foobarbaz--
क्लाइंट लाइब्रेरी का इस्तेमाल करना
नीचे दिए गए कोड सैंपल, Google API क्लाइंट लाइब्रेरी का इस्तेमाल करके एक साथ कई अनुरोध करने का तरीका बताते हैं. लाइब्रेरी इंस्टॉल करने और उन्हें सेट अप करने के तरीके के बारे में ज़्यादा जानकारी के लिए, उनके लिए बनी क्विकस्टार्ट गाइड देखें.
.NET
Java
PHP
Python
course_id = '123456' student_emails = ['alice@example.edu', 'bob@example.edu'] def callback(request_id, response, exception): if exception is not None: print 'Error adding user "{0}" to the course course: {1}'.format( request_id, exception) else: print 'User "{0}" added as a student to the course.'.format( response.get('profile').get('name').get('fullName')) batch = service.new_batch_http_request(callback=callback) for student_email in student_emails: student = { 'userId': student_email } request = service.courses().students().create(courseId=course_id, body=student) batch.add(request, request_id=student_email) batch.execute(http=http)