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

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

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

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

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

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

आंशिक संसाधनों के साथ काम करना

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

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

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

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

अधूरे जवाब

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

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

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

उदाहरण

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

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

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