json रीस्ट एपीआई-वास्तविक जीवन उदाहरणों के साथ पुट बनाम पैच




rest http (4)

सबसे पहले, कुछ परिभाषाएं:

पुट को धारा 9.6 आरएफसी 2616 में परिभाषित किया गया है:

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

पैच को आरएफसी 578 9 में परिभाषित किया गया है :

पैच विधि अनुरोध करता है कि अनुरोध इकाई में वर्णित परिवर्तनों का एक सेट अनुरोध-यूआरआई द्वारा पहचाने गए संसाधन पर लागू किया जाए।

आरएफसी 2616 के अनुसार धारा 9.1.2 पुट निष्क्रिय है जबकि पैच नहीं है।

अब एक वास्तविक उदाहरण पर नजर डालें। जब मैं डेटा {username: 'skwee357', email: '[email protected]'} साथ POST करता हूं {username: 'skwee357', email: '[email protected]'} और सर्वर संसाधन बनाने में सक्षम है, यह 201 और संसाधन स्थान के साथ जवाब देगा (मान लें /users/1 ) और GET /users/1 लिए कोई भी अगली कॉल {id: 1, username: 'skwee357', email: '[email protected]'}

अब कहें कि मैं अपना ईमेल संशोधित करना चाहता हूं। ईमेल संशोधन को "परिवर्तनों का एक सेट" माना जाता है और इसके लिए मुझे " पैच दस्तावेज़ " के साथ पैच /users/1 होना चाहिए। मेरे मामले में यह एक json {email: '[email protected]'} । सर्वर फिर 200 लौटाता है (माना जाता है कि अनुमति ठीक है)। यह मुझे पहले प्रश्न पर लाता है:

  • पैच बेवकूफ नहीं है। ऐसा आरएफसी 2616 और आरएफसी 578 9 में कहा गया। हालांकि अगर मैं एक ही पैच अनुरोध जारी करूंगा (मेरे नए ईमेल के साथ) मुझे एक ही संसाधन स्थिति मिलती है (मेरे ईमेल को अनुरोधित मूल्य में संशोधित किया जा रहा है)। पैच फिर बेवकूफ़ क्यों नहीं है?

पैच एक अपेक्षाकृत नया क्रिया है (आरएफसी मार्च 2010 में पेश किया गया), और यह "पैचिंग" की समस्या को हल करने या फ़ील्ड के एक सेट को संशोधित करने के लिए आता है। पैच पेश करने से पहले, सभी ने संसाधन अपडेट करने के लिए PUT का उपयोग किया था। लेकिन पैच पेश करने के बाद, यह मुझे उलझन में डाल देता है कि उसके लिए PUT क्या उपयोग किया जाता है? और यह मुझे दूसरे (और मुख्य) प्रश्न पर लाता है:

  • पुट और पैच के बीच असली अंतर क्या है? मैंने कहीं पढ़ा है PUT का उपयोग संपूर्ण इकाई को विशिष्ट संसाधन के तहत बदलने के लिए किया जा सकता है, इसलिए किसी को पूर्ण इकाई (पैच के साथ गुणों के सेट के बजाय) भेजनी चाहिए। ऐसे मामले के लिए वास्तविक व्यावहारिक उपयोग क्या है? आप विशिष्ट संसाधन यूआरआई के तहत किसी इकाई को प्रतिस्थापित / ओवरराइट करना कब चाहते हैं और इस तरह के ऑपरेशन को इकाई को अद्यतन / पैच करने के रूप में क्यों नहीं माना जाता है? PUT के लिए देखे जाने वाला एकमात्र व्यावहारिक उपयोग केस संग्रह पर एक पुट जारी कर रहा है, यानी /users संपूर्ण संग्रह को बदलने के लिए /users । एक विशिष्ट इकाई पर PUT जारी करने से पैच को पेश करने के बाद कोई समझ नहीं आता है। क्या मै गलत हु?

हालांकि डैन लोवे के उत्कृष्ट उत्तर ने पुट और पैच के बीच के अंतर के बारे में ओपी के सवाल का बहुत जवाब दिया, लेकिन सवाल यह है कि पैच बेवकूफ क्यों नहीं है, यह सही नहीं है।

यह दिखाने के लिए कि पैच बेवकूफ क्यों नहीं है, यह बेवकूफी की परिभाषा ( Wikipedia ) शुरू करने में मदद करता है:

Idempotent शब्द को एक ऑपरेशन का वर्णन करने के लिए अधिक व्यापक रूप से उपयोग किया जाता है जो एक बार या कई बार निष्पादित किए गए समान परिणाम उत्पन्न करेगा [...] एक idempotent फ़ंक्शन वह है जिसमें संपत्ति f (f (x)) = f (x) है कोई मूल्य एक्स।

अधिक सुलभ भाषा में, एक बेवकूफ पैच को इस प्रकार परिभाषित किया जा सकता है: पैच दस्तावेज़ के साथ संसाधन को पच करने के बाद, सभी पैच दस्तावेज़ उसी पैच दस्तावेज़ के साथ उसी संसाधन को कॉल करता है जो संसाधन को नहीं बदलेगा।

इसके विपरीत, एक गैर-idempotent ऑपरेशन एक है जहां एफ (एफ (एक्स))! = एफ (एक्स), जो पैच के लिए कहा जा सकता है: एक पैच दस्तावेज़ के साथ एक संसाधन पैचिंग के बाद, बाद में पैच उसी संसाधन के लिए कॉल एक ही पैच दस्तावेज़ संसाधन बदलते हैं।

एक गैर-idempotent पैच को चित्रित करने के लिए, मान लीजिए कि एक / उपयोगकर्ता संसाधन है, और मान लीजिए कि GET /users कॉल करना GET /users एक सूची देता है, वर्तमान में:

[{ "id": 1, "username": "firstuser", "email": "[email protected]" }]

ओपी के उदाहरण में, पैचिंग / उपयोगकर्ता / {आईडी} की बजाय, मान लीजिए कि सर्वर पैचिंग / उपयोगकर्ताओं को अनुमति देता है। आइए इस पैच अनुरोध को जारी करें:

PATCH /users
[{ "op": "add", "username": "newuser", "email": "[email protected]" }]

हमारे पैच दस्तावेज़ सर्वर की सूची में नए उपयोगकर्ता नामक एक नया उपयोगकर्ता जोड़ने के लिए सर्वर को निर्देश देता है। इसे पहली बार कॉल करने के बाद, GET /users वापस आ जाएंगे:

[{ "id": 1, "username": "firstuser", "email": "[email protected]" },
 { "id": 2, "username": "newuser", "email": "[email protected]" }]

अब, अगर हम उपरोक्त के समान सटीक पैच अनुरोध जारी करते हैं, तो क्या होता है? (इस उदाहरण के लिए, मान लें कि / उपयोगकर्ता संसाधन डुप्लिकेट उपयोगकर्ता नामों की अनुमति देता है।) "Op" "add" है, इसलिए सूची में एक नया उपयोगकर्ता जोड़ा जाता है, और बाद में GET /users लौटाते हैं:

[{ "id": 1, "username": "firstuser", "email": "[email protected]" },
 { "id": 2, "username": "newuser", "email": "[email protected]" },
 { "id": 3, "username": "newuser", "email": "[email protected]" }]

/ उपयोगकर्ता संसाधन फिर से बदल गया है , भले ही हमने सटीक उसी अंतराल के विरुद्ध सटीक एक ही पैच जारी किया हो। यदि हमारा पैच एफ (एक्स) है, एफ (एफ (एक्स)) एफ (एक्स) जैसा नहीं है, और इसलिए, यह विशेष पैच बेवकूफ नहीं है

यद्यपि पैच को बेवकूफ होने के लिए गारेट नहीं किया गया है, लेकिन पैच विनिर्देश में कुछ भी नहीं है जिससे कि आप अपने विशेष सर्वर बेवकूफ पर सभी पैच ऑपरेशन करने से रोक सकें। आरएफसी 578 9 भी बेवकूफ पैच अनुरोधों से फायदे की उम्मीद करता है:

एक पैच अनुरोध इस तरह से जारी किया जा सकता है कि वह बेवकूफ हो, जो एक ही समय पर उसी संसाधन पर दो पैच अनुरोधों के बीच टकराव से खराब परिणामों को रोकने में मदद करता है।

दान के उदाहरण में, वास्तव में, उसका पैच ऑपरेशन बेवकूफ़ है। उस उदाहरण में, / उपयोगकर्ता / 1 इकाई हमारे पैच अनुरोधों के बीच बदल गई, लेकिन हमारे पैच अनुरोधों के कारण नहीं; यह वास्तव में पोस्ट ऑफिस के अलग-अलग पैच दस्तावेज़ थे जो ज़िप कोड को बदलने के कारण थे। डाकघर का अलग पैच एक अलग ऑपरेशन है; अगर हमारा पैच एफ (एक्स) है, तो डाकघर का पैच जी (एक्स) है। बेवकूफता बताती है कि f(f(f(x))) = f(x) , लेकिन f(g(f(x))) बारे में कोई गारंटी नहीं देता है f(g(f(x)))


पुट और पैच के बीच का अंतर यह है कि:

  1. पुट को बेवकूफ होना जरूरी है। इसे प्राप्त करने के लिए, आपको अनुरोध निकाय में संपूर्ण पूरा संसाधन रखना होगा।
  2. पैच गैर-बेवकूफ हो सकता है। जिसका अर्थ है कि यह कुछ मामलों में भी बेवकूफ हो सकता है, जैसे आपके द्वारा वर्णित मामलों।

संसाधन को संशोधित करने के लिए सर्वर को बताने के लिए पैच को कुछ "पैच भाषा" की आवश्यकता होती है। कॉलर और सर्वर को कुछ "ऑपरेशंस" जैसे "एड", "प्रतिस्थापित करें", "डिलीट" को परिभाषित करने की आवश्यकता है। उदाहरण के लिए:

GET /contacts/1
{
  "id": 1,
  "name": "Sam Kwee",
  "email": "[email protected]",
  "state": "NY",
  "zip": "10001"
}

PATCH /contacts/1
{
 [{"operation": "add", "field": "address", "value": "123 main street"},
  {"operation": "replace", "field": "email", "value": "[email protected]"},
  {"operation": "delete", "field": "zip"}]
}

GET /contacts/1
{
  "id": 1,
  "name": "Sam Kwee",
  "email": "[email protected]",
  "state": "NY",
  "address": "123 main street",
}

स्पष्ट "ऑपरेशन" फ़ील्ड का उपयोग करने के बजाय, पैच भाषा इसे सम्मेलनों को परिभाषित करके अंतर्निहित कर सकती है जैसे:

पैच अनुरोध निकाय में:

  1. किसी क्षेत्र का अस्तित्व उस क्षेत्र को "प्रतिस्थापित" या "जोड़ें" का अर्थ है।
  2. यदि फ़ील्ड का मान शून्य है, तो इसका मतलब है कि उस फ़ील्ड को हटा दें।

उपरोक्त सम्मेलन के साथ, उदाहरण में पैच निम्न रूप ले सकता है:

PATCH /contacts/1
{
  "address": "123 main street",
  "email": "[email protected]",
  "zip":
}

जो अधिक संक्षिप्त और उपयोगकर्ता के अनुकूल दिखता है। लेकिन उपयोगकर्ताओं को अंतर्निहित सम्मेलन से अवगत होना चाहिए।

ऊपर वर्णित परिचालनों के साथ, पैच अभी भी बेवकूफ है। लेकिन यदि आप संचालन को परिभाषित करते हैं जैसे: "वृद्धि" या "संलग्न", तो आप आसानी से देख सकते हैं कि यह अब बेवकूफ़ नहीं होगा।


नोट : जब मैंने पहली बार आरईएसटी के बारे में पढ़ने में समय बिताया, तो मूर्खता सही होने का प्रयास करने के लिए एक भ्रमित अवधारणा थी। मुझे अभी भी मेरे मूल उत्तर में यह बिल्कुल सही नहीं मिला, क्योंकि आगे की टिप्पणियां (और जेसन होएटर का जवाब ) दिखाया गया है। थोड़ी देर के लिए, मैंने जेसन को प्रभावी ढंग से चोरी करने से बचने के लिए बड़े पैमाने पर इस उत्तर को अद्यतन करने का विरोध किया है, लेकिन अब मैं इसे संपादित कर रहा हूं क्योंकि, मुझे, टिप्पणियों में (मुझसे टिप्पणियों में) पूछा गया था।

मेरा जवाब पढ़ने के बाद, मेरा सुझाव है कि आप जेसन होएटर के इस प्रश्न का उत्कृष्ट जवाब भी पढ़ेंगे, और मैं जेसन से चोरी किए बिना अपना उत्तर बेहतर बनाने की कोशिश करूंगा।

बेवकूफ क्यों है?

जैसा कि आपने अपने आरएफसी 2616 उद्धरण में उल्लेख किया है, PUT को बेवकूफ माना जाता है। जब आप संसाधन डालते हैं, तो ये दो धारणाएं खेल में होती हैं:

  1. आप एक इकाई का जिक्र कर रहे हैं, संग्रह के लिए नहीं।

  2. जिस इकाई को आप आपूर्ति कर रहे हैं वह पूरी है ( पूरी इकाई)।

आइए आपके उदाहरणों में से एक को देखें।

{ "username": "skwee357", "email": "[email protected]" }

यदि आप इस दस्तावेज़ को /users को पोस्ट करते हैं, जैसा कि आप सुझाव देते हैं, तो आप एक इकाई वापस ले सकते हैं जैसे कि

## /users/1

{
    "username": "skwee357",
    "email": "[email protected]"
}

यदि आप बाद में इस इकाई को संशोधित करना चाहते हैं, तो आप पुट और पैच के बीच चयन करते हैं। एक पुट इस तरह दिख सकता है:

PUT /users/1
{
    "username": "skwee357",
    "email": "[email protected]"       // new email address
}

आप पैच का उपयोग कर इसे पूरा कर सकते हैं। यह ऐसा दिखाई दे सकता है:

PATCH /users/1
{
    "email": "[email protected]"       // new email address
}

आप इन दोनों के बीच तुरंत एक अंतर देखेंगे। PUT में इस उपयोगकर्ता के सभी पैरामीटर शामिल थे, लेकिन पैच में केवल उसमें शामिल किया गया था जिसे संशोधित किया जा रहा था ( email )।

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

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

गलत गलत का उपयोग करना

यदि आप PUT अनुरोध में उपरोक्त पैच डेटा का उपयोग करते हैं तो क्या होगा?

GET /users/1
{
    "username": "skwee357",
    "email": "[email protected]"
}
PUT /users/1
{
    "email": "[email protected]"       // new email address
}

GET /users/1
{
    "email": "[email protected]"      // new email address... and nothing else!
}

(मैं इस प्रश्न के प्रयोजनों के लिए मान रहा हूं कि सर्वर के पास कोई विशिष्ट आवश्यक फ़ील्ड नहीं है, और यह होने की अनुमति देगा ... जो वास्तविकता में मामला नहीं हो सकता है।)

चूंकि हमने PUT का उपयोग किया था, लेकिन केवल email की आपूर्ति की, अब यह इस इकाई में एकमात्र चीज है। इसके परिणामस्वरूप डेटा हानि हुई है।

यह उदाहरण यहां चित्रकारी उद्देश्यों के लिए है - वास्तव में ऐसा कभी नहीं करें। यह पुट अनुरोध तकनीकी रूप से बेवकूफ है, लेकिन इसका मतलब यह नहीं है कि यह एक भयानक, टूटा विचार नहीं है।

पैच कैसे बेवकूफ हो सकता है?

उपरोक्त उदाहरण में, पैच बेवकूफ था । आपने एक बदलाव किया है, लेकिन यदि आपने बार-बार वही परिवर्तन किया है, तो यह हमेशा एक ही परिणाम देगा: आपने ईमेल पता को नए मान में बदल दिया है।

GET /users/1
{
    "username": "skwee357",
    "email": "[email protected]"
}
PATCH /users/1
{
    "email": "[email protected]"       // new email address
}

GET /users/1
{
    "username": "skwee357",
    "email": "[email protected]"       // email address was changed
}
PATCH /users/1
{
    "email": "[email protected]"       // new email address... again
}

GET /users/1
{
    "username": "skwee357",
    "email": "[email protected]"       // nothing changed since last GET
}

सटीकता के लिए तय मेरा मूल उदाहरण

मेरे मूल रूप से उदाहरण थे जो मैंने सोचा था कि गैर-मूर्खता दिखा रहे थे, लेकिन वे भ्रामक / गलत थे। मैं उदाहरण रखने जा रहा हूं, लेकिन एक अलग चीज़ को चित्रित करने के लिए उनका उपयोग करें: एक ही इकाई के खिलाफ एकाधिक पैच दस्तावेज़, विभिन्न विशेषताओं को संशोधित करने, पैच को गैर-बेवकूफ़ बनाते हैं।

मान लें कि कुछ समय पहले, एक उपयोगकर्ता जोड़ा गया था। यह वह राज्य है जिसे आप से शुरू कर रहे हैं।

{
  "id": 1,
  "name": "Sam Kwee",
  "email": "[email protected]",
  "address": "123 Mockingbird Lane",
  "city": "New York",
  "state": "NY",
  "zip": "10001"
}

एक पैच के बाद, आपके पास एक संशोधित इकाई है:

PATCH /users/1
{"email": "[email protected]"}

{
  "id": 1,
  "name": "Sam Kwee",
  "email": "[email protected]",    // the email changed, yay!
  "address": "123 Mockingbird Lane",
  "city": "New York",
  "state": "NY",
  "zip": "10001"
}

यदि आप बार-बार अपने पैच को लागू करते हैं, तो आपको एक ही परिणाम मिलना जारी रहेगा: ईमेल को नए मान में बदल दिया गया था। ए चला जाता है, ए आता है, इसलिए यह बेवकूफ है।

एक घंटे बाद, कुछ कॉफी बनाने और ब्रेक लेने के बाद, कोई और अपने पैच के साथ आता है। ऐसा लगता है कि डाकघर कुछ बदलाव कर रहा है।

PATCH /users/1
{"zip": "12345"}

{
  "id": 1,
  "name": "Sam Kwee",
  "email": "[email protected]",  // still the new email you set
  "address": "123 Mockingbird Lane",
  "city": "New York",
  "state": "NY",
  "zip": "12345"                      // and this change as well
}

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

अगले दिन, आप फिर से अपना पैच भेजने का फैसला करते हैं।

PATCH /users/1
{"email": "[email protected]"}

{
  "id": 1,
  "name": "Sam Kwee",
  "email": "[email protected]",
  "address": "123 Mockingbird Lane",
  "city": "New York",
  "state": "NY",
  "zip": "12345"
}

आपके पैच का कल वही प्रभाव पड़ा है: यह ईमेल पता सेट करता है। एक अंदर चला गया, ए बाहर आया, इसलिए यह भी बेवकूफ है।

मेरे मूल जवाब में मुझे क्या गलत लगा

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

तो पैच कब बेवकूफ़ नहीं है, तो?

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


मैं इसके बारे में भी उत्सुक था और कुछ दिलचस्प लेख पाए। मैं आपके प्रश्न का पूर्ण हद तक जवाब नहीं दे सकता, लेकिन यह कम से कम कुछ और जानकारी प्रदान करता है।

http://restful-api-design.readthedocs.org/en/latest/methods.html

HTTP आरएफसी निर्दिष्ट करता है कि PUT को अनुरोध इकाई के रूप में एक पूर्ण नया संसाधन प्रतिनिधित्व लेना चाहिए। इसका अर्थ यह है कि यदि उदाहरण के लिए केवल कुछ विशेषताओं को प्रदान किया जाता है, तो उन्हें हटाया जाना चाहिए (यानी शून्य पर सेट करें)।

यह देखते हुए, फिर एक पुट को पूरी वस्तु भेजनी चाहिए। उदाहरण के लिए,

/users/1
PUT {id: 1, username: 'skwee357', email: '[email protected]'}

यह प्रभावी रूप से ईमेल को अपडेट करेगा। कारण PUT बहुत प्रभावी नहीं हो सकता है कि आपका एकमात्र वास्तव में एक क्षेत्र को संशोधित करना और उपयोगकर्ता नाम समेत बेकार है। अगला उदाहरण अंतर दिखाता है।

/users/1
PUT {id: 1, email: '[email protected]'}

अब, यदि PUT को spec के अनुसार डिज़ाइन किया गया था, तो PUT उपयोगकर्ता नाम को शून्य पर सेट करेगा और आपको निम्न वापस मिल जाएगा।

{id: 1, username: null, email: '[email protected]'}

जब आप पैच का उपयोग करते हैं, तो आप केवल उस फ़ील्ड को अपडेट करते हैं जिसे आप निर्दिष्ट करते हैं और बाकी को अपने उदाहरण के रूप में अकेले छोड़ दें।

पैच पर निम्नलिखित लेना थोड़ा अलग है जो मैंने पहले कभी नहीं देखा है।

http://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/

पुट और पैच अनुरोधों के बीच का अंतर सर्वर-संलग्न इकाई द्वारा अनुरोधित संसाधन को संशोधित करने के लिए संलग्न इकाई को संसाधित करता है। एक पुट अनुरोध में, संलग्न इकाई को मूल सर्वर पर संग्रहीत संसाधन का एक संशोधित संस्करण माना जाता है, और क्लाइंट अनुरोध कर रहा है कि संग्रहित संस्करण को प्रतिस्थापित किया जाए। पैच के साथ, हालांकि, संलग्न इकाई में निर्देशों का एक सेट होता है जो बताता है कि वर्तमान में मूल सर्वर पर मौजूद संसाधन को एक नया संस्करण बनाने के लिए संशोधित किया जाना चाहिए। पैच विधि अनुरोध-यूआरआई द्वारा पहचाने गए संसाधन को प्रभावित करती है, और यह अन्य संसाधनों पर दुष्प्रभाव भी हो सकती है; यानी, पैच के आवेदन से नए संसाधन बनाए जा सकते हैं, या मौजूदा संशोधित किए जा सकते हैं।

PATCH /users/123

[
    { "op": "replace", "path": "/email", "value": "[email protected]" }
]

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

लेख इस के साथ समाप्त होता है।

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

अब, मुझे नहीं पता कि मैं विशेष रूप से लेख के साथ सहमत हूं क्योंकि कई टिप्पणीकार बताते हैं। आंशिक प्रतिनिधित्व पर भेजना आसानी से परिवर्तनों का विवरण हो सकता है।

मेरे लिए, मैं पैच का उपयोग करने पर मिश्रित हूँ। अधिकांश भाग के लिए, मैं पुट के रूप में एक पैच के रूप में व्यवहार करूंगा क्योंकि मैंने अभी तक देखा है कि वास्तविक वास्तविक अंतर यह है कि PUT को "अनुपलब्ध मानों को शून्य पर सेट करना चाहिए"। यह करने के लिए यह 'सबसे सही' तरीका नहीं हो सकता है, लेकिन अच्छी किस्मत सही कोडिंग।





http-method