परफ़ॉर्मेंस से जुड़ी सलाह

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

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

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

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

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

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

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

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

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

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

कुछ हद तक जवाब

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

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

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

उदाहरण

नीचे दिए गए उदाहरण में, सामान्य (काल्पनिक) और कोटेशन;डेमो; एपीआई के साथ fields पैरामीटर का इस्तेमाल करने के बारे में बताया गया है.

आसान अनुरोध: यह एचटीटीपी GET अनुरोध, fields पैरामीटर को हटा देता है और पूरा रिसॉर्स दिखाता है.

https://www.googleapis.com/demo/v1

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

{
  "kind": "demo",
  ...
  "items": [
  {
    "title": "First title",
    "comment": "First comment.",
    "characteristics": {
      "length": "short",
      "accuracy": "high",
      "followers": ["Jo", "Will"],
    },
    "status": "active",
    ...
  },
  {
    "title": "Second title",
    "comment": "Second comment.",
    "characteristics": {
      "length": "long",
      "accuracy": "medium"
      "followers": [ ],
    },
    "status": "pending",
    ...
  },
  ...
  ]
}

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

https://www.googleapis.com/demo/v1?fields=kind,items(title,characteristics/length)

कुछ हिस्से के जवाब: ऊपर दिए गए अनुरोध के जवाब में, सर्वर एक रिस्पॉन्स भेजता है जिसमें कम जानकारी वाले सिर्फ़ एक आइटम की जानकारी होती है. इसमें, हर आइटम में सिर्फ़ एचटीएमएल शीर्षक और लंबाई वाली विशेषता शामिल होती है.

200 OK

{
  "kind": "demo",
  "items": [{
    "title": "First title",
    "characteristics": {
      "length": "short"
    }
  }, {
    "title": "Second title",
    "characteristics": {
      "length": "long"
    }
  },
  ...
  ]
}

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

इसके बाद, fields पैरामीटर को फ़ॉर्मैट करने के तरीके के बारे में जानकारी मिलती है. इसके बाद, रिस्पॉन्स में क्या मिलता है, इस बारे में ज़्यादा जानकारी दी गई है.

फ़ील्ड पैरामीटर के सिंटैक्स की खास जानकारी

fields अनुरोध के पैरामीटर की वैल्यू मुख्य रूप से XPath सिंटैक्स के आधार पर तय की जाती है. इस्तेमाल किए जा सकने वाले सिंटैक्स की खास जानकारी नीचे दी गई है. साथ ही, नीचे दिए गए सेक्शन में और भी उदाहरण दिए गए हैं.

• एक से ज़्यादा फ़ील्ड चुनने के लिए, कॉमा-सेपरेटेड लिस्ट का इस्तेमाल करें.
• a का इस्तेमाल करने वाली फ़ील्ड b को चुनने के लिए, a/b का इस्तेमाल करें. b में नेस्ट की गई फ़ील्ड चुनने के लिए, a/b/c का इस्तेमाल करें.
  

  अपवाद: ऐसे एपीआई रिस्पॉन्स के लिए "data" रैपर, जहां data: { ... } जैसा data ऑब्जेक्ट में जवाब नेस्ट किया गया है, fields की खास जानकारी में "data" शामिल न करें. data/a/b जैसे फ़ील्ड की खास जानकारी के साथ डेटा ऑब्जेक्ट शामिल करने से गड़बड़ी होती है. इसके बजाय, a/b जैसी fields की जानकारी का इस्तेमाल करें.

• श्रेणियों या ऑब्जेक्ट में खास सब-फ़ील्ड के सेट का अनुरोध करने के लिए, सब-सिलेक्टर का इस्तेमाल करें. इसके लिए, ब्रैकेट में &कोट करें;( )".

  उदाहरण के लिए: fields=items(id,author/email), आइटम कैटगरी के हर एलिमेंट के लिए, सिर्फ़ सामान का आईडी और लेखक का ईमेल पता दिखाता है. एक सब-फ़ील्ड भी तय किया जा सकता है, जहां fields=items(id), fields=items/id के बराबर है.

• अगर ज़रूरी हो, तो फ़ील्ड चुनने के लिए वाइल्डकार्ड का इस्तेमाल करें.

  उदाहरण के लिए: fields=items/pagemap/*, पेजमैप में सभी ऑब्जेक्ट चुनता है.

फ़ील्ड पैरामीटर का इस्तेमाल करने के ज़्यादा उदाहरण

नीचे दिए गए उदाहरणों में बताया गया है कि fields पैरामीटर की वैल्यू से रिस्पॉन्स पर क्या असर पड़ता है.

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

उन फ़ील्ड की पहचान करें जिन्हें आपको दिखाना है या फ़ील्ड चुनें.

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

यहां कलेक्शन के लिए कुछ उदाहरण दिए गए हैं:

उदाहरण	असर
items	आइटम श्रेणी के सभी एलिमेंट दिखाता है, जिसमें हर एलिमेंट के सभी फ़ील्ड शामिल होते हैं, लेकिन कोई दूसरा फ़ील्ड नहीं होता.
etag,items	यह etag फ़ील्ड और आइटम की कैटगरी के सभी एलिमेंट दिखाता है.
items/title	आइटम कैटगरी में सभी एलिमेंट के लिए, सिर्फ़ title फ़ील्ड दिखाता है. नेस्ट किए गए किसी फ़ील्ड को लौटाने पर, रिस्पॉन्स में एनक्लोज़िंग पैरंट ऑब्जेक्ट शामिल होते हैं. पैरंट फ़ील्ड में कोई अन्य चाइल्ड फ़ील्ड शामिल नहीं होता है, जब तक कि उन्हें भी साफ़ तौर पर नहीं चुना जाता.
context/facets/label	facets कैटगरी के सभी सदस्यों के लिए, सिर्फ़ label फ़ील्ड दिखाता है. इसे context ऑब्जेक्ट के तहत नेस्ट किया जाता है.
items/pagemap/*/title	आइटम कैटगरी में हर एलिमेंट के लिए, सिर्फ़ उन सभी ऑब्जेक्ट के title फ़ील्ड (अगर मौजूद हो) दिखाता है जो pagemap के चाइल्ड हैं.

यहां रिसॉर्स लेवल के कुछ उदाहरण दिए गए हैं:

उदाहरण	असर
title	अनुरोध किए गए संसाधन का title फ़ील्ड दिखाता है.
author/uri	अनुरोध किए गए रिसॉर्स में author ऑब्जेक्ट का uri सब-फ़ील्ड दिखाता है.
links/*/href	links के चाइल्ड ऑब्जेक्ट के सभी ऑब्जेक्ट का href फ़ील्ड दिखाता है.

सब-सिलेक्शन का इस्तेमाल करके, खास फ़ील्ड के सिर्फ़ कुछ हिस्सों के लिए अनुरोध करें.

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

उदाहरण	असर
items(title,author/uri)	आइटम कैटगरी में हर एलिमेंट के लिए, सिर्फ़ title और लेखक के uri की वैल्यू दिखाता है.

आंशिक जवाबों को हैंडल करना

जब सर्वर मान्य अनुरोध को प्रोसेस करता है, जिसमें fields क्वेरी पैरामीटर शामिल होता है, तो यह अनुरोध किए गए डेटा के साथ एचटीटीपी 200 OK स्टेटस कोड दिखाता है. अगर fields क्वेरी पैरामीटर में कोई गड़बड़ी है या वह अमान्य है, तो सर्वर एक एचटीटीपी 400 Bad Request स्टेटस कोड के साथ गड़बड़ी का मैसेज दिखाता है. इसमें उपयोगकर्ता को बताया जाता है कि उनके फ़ील्ड चुनने में क्या समस्या हुई. उदाहरण के लिए, "Invalid field selection a/b".

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

https://www.googleapis.com/demo/v1?fields=kind,items(title,characteristics/length)

आंशिक जवाब कुछ ऐसा दिखता है:

200 OK

{
  "kind": "demo",
  "items": [{
    "title": "First title",
    "characteristics": {
      "length": "short"
    }
  }, {
    "title": "Second title",
    "characteristics": {
      "length": "long"
    }
  },
  ...
  ]
}

ध्यान दें: डेटा पेजों को क्रम में लगाने के लिए क्वेरी पैरामीटर के साथ काम करने वाले एपीआई के लिए (उदाहरण के लिए, maxResults और nextPageToken), हर क्वेरी के नतीजों को मैनेज करने लायक साइज़ तक कम करने के लिए, उन पैरामीटर का इस्तेमाल करें. ऐसा न करने पर, हो सकता है कि परफ़ॉर्मेंस का कुछ हिस्सा सही से काम न करे.

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

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

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

उदाहरण

यह उदाहरण सिर्फ़ सामान्य (काल्पनिक) "Demo" एपीआई संसाधन का शीर्षक अपडेट करने के लिए पैच अनुरोध दिखाता है. इस संसाधन में एक टिप्पणी, विशेषताओं का एक सेट, स्थिति और कई दूसरे फ़ील्ड भी हैं, लेकिन यह अनुरोध सिर्फ़ title फ़ील्ड भेजता है, क्योंकि इसमें सिर्फ़ एक फ़ील्ड बदला जा रहा है:

PATCH https://www.googleapis.com/demo/v1/324
Authorization: Bearer your_auth_token
Content-Type: application/json

{
  "title": "New title"
}

जवाब:

200 OK

{
  "title": "New title",
  "comment": "First comment.",
  "characteristics": {
    "length": "short",
    "accuracy": "high",
    "followers": ["Jo", "Will"],
  },
  "status": "active",
  ...
}

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

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

पैच अनुरोध के सिमैंटिक

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

• जोड़ें: अगर किसी ऐसे फ़ील्ड को जोड़ना है जो पहले से मौजूद नहीं है, तो नए फ़ील्ड और उसकी वैल्यू की जानकारी दें.
• बदलाव करें: किसी मौजूदा फ़ील्ड की वैल्यू बदलने के लिए, फ़ील्ड तय करें और उसे नई वैल्यू पर सेट करें.
  
• मिटाएं: कोई फ़ील्ड मिटाने के लिए, फ़ील्ड की जानकारी दें और उसे null पर सेट करें. उदाहरण के लिए, "comment": null. null पर सेट करके, पूरे ऑब्जेक्ट (अगर इसमें बदलाव किया जा सकता है) को भी मिटाया जा सकता है. अगर आप Java एपीआई क्लाइंट लाइब्रेरी का इस्तेमाल कर रहे हैं, तो इसके बजाय Data.NULL_STRING का इस्तेमाल करें. ज़्यादा जानकारी के लिए, JSON शून्य देखें.

श्रेणियों के बारे में ध्यान दें: श्रेणियों के अनुरोध वाले पैच, मौजूदा श्रेणी को उस श्रेणी से बदल देते हैं जो आपने दी है. किसी श्रेणी में आइटम को संशोधित, जोड़ा या हटाया नहीं जा सकता.

रीडिंग-राइट-राइट साइकल में पैच का इस्तेमाल करना

आप जिस डेटा में बदलाव करना चाहते हैं उसका आंशिक जवाब देकर शुरुआत करने के लिए, यह एक अच्छा तरीका हो सकता है. यह खास तौर पर Eटैग का इस्तेमाल करने वाले संसाधनों के लिए ज़रूरी है, क्योंकि संसाधन को अपडेट करने के लिए आपको If-Match एचटीटीपी हेडर में मौजूदा इटैग मान देना होगा. डेटा मिलने के बाद, आप उन वैल्यू में बदलाव कर सकते हैं जिन्हें आप बदलना चाहते हैं. इसके बाद, आप बदलाव के कुछ हिस्से को पैच अनुरोध के साथ वापस भेज सकते हैं. यहां एक उदाहरण दिया गया है, जो यह मानता है कि डेमो संसाधन ETags का इस्तेमाल करता है:

GET https://www.googleapis.com/demo/v1/324?fields=etag,title,comment,characteristics
Authorization: Bearer your_auth_token

यह आंशिक जवाब है:

200 OK

{
  "etag": "ETagString"
  "title": "New title"
  "comment": "First comment.",
  "characteristics": {
    "length": "short",
    "level": "5",
    "followers": ["Jo", "Will"],
  }
}

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

PATCH https://www.googleapis.com/demo/v1/324?fields=etag,title,comment,characteristics
Authorization: Bearer your_auth_token
Content-Type: application/json
If-Match: "ETagString"

{
  "etag": "ETagString"
  "title": "",                  /* Clear the value of the title by setting it to the empty string. */
  "comment": null,              /* Delete the comment by replacing its value with null. */
  "characteristics": {
    "length": "short",
    "level": "10",              /* Modify the level value. */
    "followers": ["Jo", "Liz"], /* Replace the followers array to delete Will and add Liz. */
    "accuracy": "high"          /* Add a new characteristic. */
  },
}

सर्वर, 200 ओके एचटीटीपी स्टेटस कोड और अपडेट किए गए रिसॉर्स के कुछ हिस्सों के साथ रिस्पॉन्स देता है:

200 OK

{
  "etag": "newETagString"
  "title": "",                 /* Title is cleared; deleted comment field is missing. */
  "characteristics": {
    "length": "short",
    "level": "10",             /* Value is updated.*/
    "followers": ["Jo" "Liz"], /* New follower Liz is present; deleted Will is missing. */
    "accuracy": "high"         /* New characteristic is present. */
  }
}

सीधे पैच अनुरोध बनाना

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

ध्यान दें: ETag का इस्तेमाल किए जाने पर, पैच को ज़बरदस्ती इस्तेमाल करने के लिए, "If-Match: *" एचटीटीपी हेडर का इस्तेमाल किया जा सकता है. अगर आप ऐसा करते हैं, तो आपको लिखने से पहले पढ़ने की ज़रूरत नहीं है.

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

PATCH https://www.googleapis.com/demo/v1/324?fields=comment,characteristics
Authorization: Bearer your_auth_token
Content-Type: application/json

{
  "comment": "A new comment",
  "characteristics": {
    "volume": "loud",
    "accuracy": null
  }
}

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

पैच का जवाब देना

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

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