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

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

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

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

  अपवाद: "डेटा" रैपर का इस्तेमाल करने वाले एपीआई रिस्पॉन्स के लिए, जहां रिस्पॉन्स 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	आइटम कैटगरी में मौजूद हर एलिमेंट के लिए, pagemap के चाइल्ड ऑब्जेक्ट के सिर्फ़ title फ़ील्ड (अगर मौजूद हो) दिखाता है.

यहां संसाधन के कुछ उदाहरण दिए गए हैं:

उदाहरण	असर
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 लागू करने की प्रक्रिया से अलग (और आसान) हैं.

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

उदाहरण

इस उदाहरण में, सिर्फ़ सामान्य (काल्पनिक) "डेमो" एपीआई रिसॉर्स के शीर्षक को अपडेट करने का अनुरोध किया गया है. संसाधन में एक टिप्पणी, विशेषताओं का एक सेट, स्थिति और कई दूसरे फ़ील्ड भी शामिल हैं, लेकिन यह अनुरोध सिर्फ़ 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 API क्लाइंट लाइब्रेरी का इस्तेमाल कर रहे हैं, तो इसके बजाय Data.NULL_STRING का इस्तेमाल करें. ज़्यादा जानकारी के लिए JSON नल देखें.

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

पढ़ें-बदलाव-लिखें साइकल में पैच का इस्तेमाल करना

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

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 OK एचटीटीपी स्टेटस कोड और अपडेट किए गए रिसॉर्स के कुछ हिस्से के साथ रिस्पॉन्स करता है:

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. */
  }
}

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

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

ध्यान दें: आप चाहें, तो "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 का इस्तेमाल करता है, तो सर्वर पैच टैग के अनुरोध को प्रोसेस करने के लिए ETag वैल्यू को अपडेट करता है, जैसा कि PUT के साथ करता है.

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

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

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

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

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

पैच और अपडेट के बीच का अंतर

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

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