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

इस दस्तावेज़ में, ऐप्लिकेशन की परफ़ॉर्मेंस को बेहतर बनाने के लिए इस्तेमाल की जा सकने वाली कुछ तकनीकों के बारे में बताया गया है. कुछ मामलों में, बताए गए आइडिया को समझाने के लिए, अन्य एपीआई या सामान्य एपीआई के उदाहरणों का इस्तेमाल किया जाता है. हालांकि, यही कॉन्सेप्ट Google Drive API पर भी लागू होते हैं.

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

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

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

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

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

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

आंशिक अनुरोध दो तरह के होते हैं:

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

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

अधूरे जवाब

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

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

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

उदाहरण

पैच (आंशिक अपडेट)

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

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

उदाहरण

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

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

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

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

PATCH HTTP वर्ब काम न करने पर, दूसरा नोटेशन

अगर आपका फ़ायरवॉल, एचटीटीपी PATCH अनुरोधों की अनुमति नहीं देता है, तो एचटीटीपी POST अनुरोध करें और ओवरराइड हेडर को PATCH पर सेट करें. ऐसा नीचे दिए गए तरीके से करें:

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

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

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

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

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

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

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

खास जानकारी

क्लाइंट के हर एचटीटीपी कनेक्शन से कुछ हद तक ओवरहेड होता है. 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 API के कई कॉल शामिल होते हैं. मुख्य एचटीटीपी अनुरोध में, हर हिस्से में नेस्ट किया गया एचटीटीपी अनुरोध होता है.

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

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

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

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

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

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

सर्वर का जवाब, 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--

अनुरोध से कुछ फ़ील्ड की वैल्यू वापस पाना

अगर आपने fields पैरामीटर तय नहीं किया है, तो सर्वर, तरीके के हिसाब से फ़ील्ड का डिफ़ॉल्ट सेट दिखाता है. उदाहरण के लिए, files.list तरीके से सिर्फ़ kind, id, name, और mimeType फ़ील्ड की वैल्यू मिलती है.

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

about, comments (delete को छोड़कर), और replies (delete को छोड़कर) संसाधनों के सभी तरीकों के लिए, आपको fields पैरामीटर सेट करना ज़रूरी है. इन तरीकों से, फ़ील्ड का डिफ़ॉल्ट सेट नहीं मिलता.