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




rest http (6)

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

PUT को धारा 9.6 RFC 2616 में परिभाषित किया गया है:

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

PATCH को RFC 5789 में परिभाषित किया गया है :

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

इसके अलावा RFC 2616 धारा 9.1.2 PUT के अनुसार बेरोजगार है जबकि PATCH नहीं है।

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

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

  • पथ बेकार नहीं है। यह RFC 2616 और RFC 5789 में ऐसा कहा गया है। हालाँकि, अगर मैं उसी PATCH अनुरोध (अपने नए ईमेल के साथ) जारी करूंगा तो बीमार को उसी संसाधन की स्थिति मिलेगी (मेरे ईमेल को अनुरोधित मूल्य में संशोधित किया जाएगा)। PATCH क्यों नहीं है फिर भी बेरोजगार?

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

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

https://code.i-harness.com


TLDR - डंबल डाउन संस्करण

PUT => मौजूदा संसाधन के लिए सभी नई विशेषताएँ सेट करें।

PATCH => आंशिक रूप से एक मौजूदा संसाधन (सभी विशेषताओं की आवश्यकता नहीं) को अपडेट करें।


PUT और PATCH के बीच अंतर यह है कि:

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

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

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",
}

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

PATCH अनुरोध निकाय में:

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

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

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

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

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


मुझे पहले से टिप्पणी में उद्धृत RFC 7231 सेक्शन 4.2.2 पर अधिक बारीकी से उद्धृत करने और टिप्पणी करने दें:

एक अनुरोध विधि को "निष्पादनीय" माना जाता है यदि उस विधि के साथ कई समान अनुरोधों के सर्वर पर इच्छित प्रभाव एकल एकल अनुरोध के लिए प्रभाव के समान है। इस विनिर्देशन, PUT, DELETE और सुरक्षित अनुरोध विधियों द्वारा परिभाषित अनुरोध विधियों में से एक हैं।

(...)

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

तो, एक बेकार विधि के बार-बार अनुरोध के बाद "वही" क्या होना चाहिए? न सर्वर राज्य, न ही सर्वर प्रतिक्रिया, लेकिन इच्छित प्रभाव । विशेष रूप से, विधि को "ग्राहक के दृष्टिकोण से" बेरोजगार होना चाहिए। अब, मुझे लगता है कि इस दृष्टिकोण से पता चलता है कि डैन लोव के जवाब में अंतिम उदाहरण, जिसे मैं यहाँ पर टालना नहीं चाहता, वास्तव में यह दर्शाता है कि एक PATCH अनुरोध गैर-बेरोजगार हो सकता है (उदाहरण से अधिक प्राकृतिक तरीके से) जेसन होएगर का जवाब )।

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

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

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

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


मेरी विनम्र राय में, मूर्खता का अर्थ है:

  • रखना:

मैं एक प्रतिस्पर्धा संसाधन परिभाषा भेजता हूं, इसलिए - परिणामी संसाधन स्थिति ठीक उसी तरह से परिभाषित की जाती है जैसे कि PUT परमेस द्वारा। प्रत्येक बार जब मैं एक ही PUT परम के साथ संसाधन को अपडेट करता हूं - परिणामी स्थिति बिल्कुल समान है।

  • PATCH:

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

किसी वस्तु को निम्नानुसार परिभाषित करें:

कार: - रंग: काला, प्रकार: पालकी, - सीटें: 5

मैं इसके साथ पैच:

{लाल रंग'}

परिणामी वस्तु है:

कार: - रंग: लाल, प्रकार: पालकी, - सीटें: 5

फिर, कुछ अन्य उपयोगकर्ताओं ने इस कार को पैच किया:

{टाइप: 'हैचबैक'}

इसलिए, परिणामी वस्तु है:

कार: - रंग: लाल, - प्रकार: हैचबैक, - सीटें: 5

अब, अगर मैं इस ऑब्जेक्ट को फिर से पैच करता हूं:

{लाल रंग'}

परिणामी वस्तु है:

कार: - रंग: लाल, - प्रकार: हैचबैक, - सीटें: 5

जो मुझे पहले मिला है, उसके लिए क्या अलग है!

यही कारण है कि पीएटीएचए आदर्शहीन नहीं है, जबकि पीयूटी बेरोजगार है।


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

यह दिखाने के लिए कि PATCH क्यों नहीं है, यह बेरोजगारी ( Wikipedia ) की परिभाषा के साथ शुरू करने में मदद करता है:

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

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

इसके विपरीत, एक गैर-निष्क्रिय ऑपरेशन वह है जिसमें f (f (x))! = F (x) होता है, जिसे PATCH के लिए कहा जा सकता है: पैच डॉक्यूमेंट के साथ एक संसाधन को प्राप्त करने के बाद, बाद में PATCH उसी संसाधन के साथ कॉल करता है। एक ही पैच दस्तावेज़ संसाधन को बदलता है।

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

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

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

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" "ऐड" है, इसलिए सूची में एक नया उपयोगकर्ता जोड़ा जाता है, और बाद में GET /users वापस आ जाते हैं:

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

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

हालांकि, PATCH को निष्प्रभावी होने की गारंटी नहीं है, लेकिन आपके विशेष सर्वर के सभी PATCH परिचालनों को बनाने से रोकने के लिए PATCH विनिर्देश में कुछ भी नहीं है। RFC 5789 भी बेमिसाल PATCH अनुरोधों से लाभ की आशा करता है:

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

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


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

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

क्यों है PUT सुस्पष्ट?

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

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

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

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

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

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

## /users/1

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

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

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

आप PATCH का उपयोग करके इसे पूरा कर सकते हैं। यह इस तरह लग सकता है:

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

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

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

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

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

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

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 की आपूर्ति की, अब इस इकाई में केवल यही एक चीज है। इससे डेटा हानि हुई है।

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

PATCH को कैसे बनाया जा सकता है?

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

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
}

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

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

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

{
  "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"
}

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

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

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 ईमेल से ही चिंता नहीं करता है, केवल ज़िप कोड, यदि इसे बार-बार लागू किया जाता है, तो इसे भी वही परिणाम मिलेगा: ज़िप कोड नए मूल्य पर सेट होता है। A अंदर जाता है, A बाहर आता है, इसलिए यह भी बेकार है।

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

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"
}

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

मेरे मूल उत्तर में मुझे क्या गलत लगा

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

तो जब PATCH बेकार नहीं है, तब?

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





http-method