प्रदर्शन सुधारें

gzip का इस्तेमाल करके कंप्रेस करना

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

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

Accept-Encoding: gzip
User-Agent: my program (gzip)

कुछ संसाधनों के साथ काम करना

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

कुछ हिस्से के लिए अनुरोध दो तरह के होते हैं:

• कुछ हिस्से का जवाब: यह एक ऐसा अनुरोध है जिसमें यह बताया जाता है कि रिस्पॉन्स में कौनसे फ़ील्ड शामिल करने हैं. इसके लिए, fields अनुरोध पैरामीटर का इस्तेमाल करें.
• पैच: अपडेट का अनुरोध, जिसमें सिर्फ़ वे फ़ील्ड भेजे जाते हैं जिनमें बदलाव करना है. इसके लिए, PATCH एचटीटीपी वर्ब का इस्तेमाल करें.

कुछ डेटा के लिए अनुरोध करने के बारे में ज़्यादा जानकारी, यहां दिए गए सेक्शन में दी गई है.

अधूरे जवाब

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

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

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

उदाहरण

पैच (कुछ हिस्से का अपडेट)

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

नीचे दिए गए छोटे उदाहरण में दिखाया गया है कि पैच का इस्तेमाल करके, छोटा अपडेट करने के लिए, आपको कितना कम डेटा भेजना पड़ता है.

उदाहरण

पैच के जवाब को मैनेज करना

मान्य पैच अनुरोध को प्रोसेस करने के बाद, एपीआई बदले गए संसाधन के पूरे रेप्रज़ेंटेशन के साथ-साथ 200 OK एचटीटीपी रिस्पॉन्स कोड दिखाता है. अगर एपीआई में ETag का इस्तेमाल किया जाता है, तो सर्वर, पैच अनुरोध को प्रोसेस करने के बाद ETag की वैल्यू अपडेट करता है. यह ठीक वैसे ही होता है जैसे PUT के साथ होता है.

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

अगर पैच अनुरोध की वजह से, संसाधन की नई स्थिति सिंटैक्टिक या सेमेटिक तौर पर अमान्य होती है, तो सर्वर 400 Bad Request या 422 Unprocessable Entity एचटीटीपी स्टेटस कोड दिखाता है. साथ ही, संसाधन की स्थिति में कोई बदलाव नहीं होता. उदाहरण के लिए, अगर किसी ज़रूरी फ़ील्ड की वैल्यू मिटाने की कोशिश की जाती है, तो सर्वर गड़बड़ी का मैसेज दिखाता है.

PATCH एचटीटीपी वर्ब काम न करने पर, वैकल्पिक नोटेशन

अगर आपका फ़ायरवॉल, एचटीटीपी PATCH रिक्वेस्ट की अनुमति नहीं देता है, तो एचटीटीपी POST रिक्वेस्ट करें और बदले गए हेडर को PATCH पर सेट करें, जैसा कि यहां दिखाया गया है:

POST https://www.googleapis.com/...
X-HTTP-Method-Override: PATCH
...

पैच और अपडेट में अंतर

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

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

खास जानकारी

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

ऐसे मामलों के उदाहरण जिनमें आपको एक साथ कई फ़ाइलें अपलोड करनी होंगी:

• बड़ी संख्या में फ़ाइलों का मेटाडेटा हासिल करना.
• मेटाडेटा या प्रॉपर्टी को एक साथ अपडेट करना.
• बड़ी संख्या में फ़ाइलों की अनुमतियां बदलना. जैसे, नया उपयोगकर्ता या ग्रुप जोड़ना.
• पहली बार या लंबे समय तक ऑफ़लाइन रहने के बाद, लोकल क्लाइंट डेटा को सिंक करना.

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

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

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

अन्य पाबंदियों में ये शामिल हैं:

• 100 से ज़्यादा कॉल वाले बैच अनुरोधों की वजह से गड़बड़ी हो सकती है.
• हर इनर रिक्वेस्ट के लिए, यूआरएल की लंबाई 8,000 वर्णों से ज़्यादा नहीं होनी चाहिए.
• Google Drive में, मीडिया को एक साथ अपलोड या डाउनलोड करने या फ़ाइलों को एक्सपोर्ट करने की सुविधा उपलब्ध नहीं है.

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

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

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

एक साथ कई अनुरोध करने का फ़ॉर्मैट

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

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

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

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

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

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

एक साथ कई अनुरोध करने पर मिलने वाला जवाब

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

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

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

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

उदाहरण

इस उदाहरण में, Google Drive API के साथ एक साथ कई फ़ाइलें अपलोड करने का तरीका बताया गया है.

एक साथ कई अनुरोध करने का उदाहरण

POST https://www.googleapis.com/batch/drive/v3
Accept-Encoding: gzip
User-Agent: Google-HTTP-Java-Client/1.20.0 (gzip)
Content-Type: multipart/mixed; boundary=END_OF_PART
Content-Length: 963


--END_OF_PART
Content-Length: 337
Content-Type: application/http
content-id: 1
content-transfer-encoding: binary

POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id
Authorization: Bearer authorization_token
Content-Length: 70
Content-Type: application/json; charset=UTF-8

{
  "emailAddress":"example@appsrocks.com",
  "role":"writer",
  "type":"user"
}
--END_OF_PART
Content-Length: 353
Content-Type: application/http
content-id: 2
content-transfer-encoding: binary

POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id&sendNotificationEmail=false
Authorization: Bearer authorization_token
Content-Length: 58
Content-Type: application/json; charset=UTF-8

{
   "domain":"appsrocks.com",
   "role":"reader",
   "type":"domain"
}
--END_OF_PART--

एक साथ कई अनुरोधों के जवाब का उदाहरण

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

HTTP/1.1 200 OK
Alt-Svc: quic=":443"; p="1"; ma=604800
Server: GSE
Alternate-Protocol: 443:quic,p=1
X-Frame-Options: SAMEORIGIN
Content-Encoding: gzip
X-XSS-Protection: 1; mode=block
Content-Type: multipart/mixed; boundary=batch_6VIxXCQbJoQ_AATxy_GgFUk
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
Date: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Vary: X-Origin
Vary: Origin
Expires: Fri, 13 Nov 2015 19:28:59 GMT


--batch_6VIxXCQbJoQ_AATxy_GgFUk
Content-Type: application/http
Content-ID: response-1

HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Date: Fri, 13 Nov 2015 19:28:59 GMT
Expires: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Content-Length: 35

{
 "id": "12218244892818058021i"
}

--batch_6VIxXCQbJoQ_AATxy_GgFUk
Content-Type: application/http
Content-ID: response-2

HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Date: Fri, 13 Nov 2015 19:28:59 GMT
Expires: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Content-Length: 35

{
 "id": "04109509152946699072k"
}

--batch_6VIxXCQbJoQ_AATxy_GgFUk--