प्रदर्शन सुझाव

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

  • एक से ज़्यादा फ़ील्ड चुनने के लिए, कॉमा लगाकर सूची बनाएं.
  • 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 items कलेक्शन में मौजूद सभी एलिमेंट दिखाता है. इसमें हर एलिमेंट के सभी फ़ील्ड शामिल होते हैं, लेकिन कोई अन्य फ़ील्ड नहीं.
etag,items आइटम कलेक्शन में मौजूद etag फ़ील्ड और सभी एलिमेंट दिखाता है.
items/title आइटम कलेक्शन में मौजूद सभी एलिमेंट के लिए, सिर्फ़ title फ़ील्ड दिखाता है.

जब भी नेस्ट किया गया कोई फ़ील्ड दिखाया जाता है, तो रिस्पॉन्स में उस फ़ील्ड को शामिल करने वाले पैरंट ऑब्जेक्ट भी शामिल होते हैं. पैरंट फ़ील्ड में तब तक कोई दूसरा चाइल्ड फ़ील्ड शामिल नहीं होता, जब तक कि उसे साफ़ तौर पर नहीं चुना जाता.
context/facets/label यह फ़ंक्शन, facets कलेक्शन के सभी सदस्यों के लिए सिर्फ़ label फ़ील्ड दिखाता है. यह कलेक्शन, context ऑब्जेक्ट के तहत नेस्ट होता है.
items/pagemap/*/title items कलेक्शन के हर एलिमेंट के लिए, 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) का इस्तेमाल करने वाले एपीआई के लिए, हर क्वेरी के नतीजों को मैनेज किए जा सकने वाले साइज़ में कम करने के लिए, उन पैरामीटर का इस्तेमाल करें. ऐसा न करने पर, हो सकता है कि आंशिक जवाब देने से मिलने वाले परफ़ॉर्मेंस फ़ायदे न मिलें.

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

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

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

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

जिस डेटा में बदलाव करना है उसके साथ कुछ जवाब वापस पाकर शुरुआत करना एक अच्छा तरीका हो सकता है. यह खास तौर पर उन संसाधनों के लिए ज़रूरी है जो ETag का इस्तेमाल करते हैं. ऐसा इसलिए है, क्योंकि संसाधन को अपडेट करने के लिए, आपको If-Match एचटीटीपी हेडर में मौजूदा ETag वैल्यू देनी होगी. डेटा मिलने के बाद, उन वैल्यू में बदलाव किया जा सकता है जिन्हें आपको बदलना है. इसके बाद, पैच अनुरोध के साथ बदली गई वैल्यू को वापस भेजा जा सकता है. यहां एक उदाहरण दिया गया है, जिसमें यह माना गया है कि डेमो रिसॉर्स में 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. */
  }
}

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

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

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