परफ़ॉर्मेंस बेहतर करना

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

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

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

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

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

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

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

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

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

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

अधूरे जवाब का अनुरोध

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

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

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

पैच (कुछ हिस्सों के लिए अपडेट)

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

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

उदाहरण

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

पैच के मान्य अनुरोध को प्रोसेस करने के बाद, एपीआई, 200 OK एचटीटीपी रिस्पॉन्स कोड के साथ-साथ, बदले गए संसाधन का पूरा डेटा दिखाता है. अगर एपीआई, ETags का इस्तेमाल करता है, तो सर्वर, पैच के अनुरोध को सफलतापूर्वक प्रोसेस करने पर, 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 की क्लाइंट लाइब्रेरी का इस्तेमाल किया जा रहा है, तो क्लाइंट लाइब्रेरी का दस्तावेज़ देखें.

खास जानकारी

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

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

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

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

सर्वर का जवाब, 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 पैरामीटर सेट करना ज़रूरी है. ये तरीके, फ़ील्ड का डिफ़ॉल्ट सेट नहीं दिखाते.