PATCH विधि क्यों नहीं है?

Question

मैं इस बारे में सोच रहा था।

मान लीजिए कि मेरे पास और खेतों के userसाथ एक संसाधन है । अगर मैं किसी क्षेत्र को अपडेट करना चाहता हूं तो मैं इस तरह से संसाधन के लिए एक पाच अनुरोध कर सकता हूंidname

PATCH /users/42
{"name": "john doe"} 

और फिर एप्लिकेशन उपयोगकर्ता 42 नाम को अपडेट करेगा।

लेकिन अगर मैं इस अनुरोध को दोहराता हूं तो परिणाम अलग होगा?

RFC 5789 के अनुसार

PATCH न तो सुरक्षित है और न ही बेकार है

Comments

क्या होगा अगर किसी और के बीच में कोई अन्य उपयोगकर्ता 42 को अपडेट करने का अनुरोध करता है{"name": "bendjamin franklin"}

— gnat

@gnat PUT पद्धति के लिए भी एक समान तर्क नहीं रखता है, जिसे इसके बजाय उदासीन माना जाता है? (देखें goo.gl/t24ZSJ )

— मट्टकेपु

"पीयूटी के पास अप्रभावी शब्दार्थ है और इस प्रकार इसे पूर्ण अपडेट के लिए सुरक्षित रूप से उपयोग किया जा सकता है (अर्थात हम संसाधन की संपूर्ण स्थिति सर्वर को भेजते हैं), लेकिन सापेक्ष अपडेट के लिए भी नहीं (अर्थात हम संसाधन स्थिति में केवल परिवर्तन भेजते हैं) , क्योंकि यह उल्लंघन होगा। इसका शब्दार्थ ... "( POST और PUT अनुरोध - क्या यह सिर्फ सम्मेलन है? )

— gnat

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

— मट्टकेपु

मैंने प्रासंगिक विनिर्देश के संदर्भ को जोड़ने की स्वतंत्रता ली, क्योंकि मेरा मानना ​​है कि इस प्रश्न के संदर्भ में यह बहुत प्रासंगिक है।

— पीट

Answer 1

PATCH अनुरोध निष्प्राण हो सकता है, लेकिन यह होना आवश्यक नहीं है। यही कारण है कि इसे गैर-बेरोजगारी के रूप में जाना जाता है।

PATCH सुस्पष्ट हो सकता है या नहीं, यह इस बात पर बहुत निर्भर करता है कि आवश्यक परिवर्तन कैसे संप्रेषित किए जाते हैं।
उदाहरण के लिए, यदि पैच प्रारूप के रूप में है {change: 'Name' from: 'benjamin franklin' to: 'john doe'}, तो पहले के बाद किसी भी पाच अनुरोध के पहले अनुरोध की तुलना में एक अलग प्रभाव (विफलता की प्रतिक्रिया) होगा।
नॉन-इम्पोटेन्सी का एक और कारण यह हो सकता है कि मूल संसाधन की तुलना में किसी अन्य चीज़ पर संशोधन लागू करने से संसाधन अमान्य हो सकता है। यदि आप कई बार परिवर्तन लागू करते हैं तो यह भी मामला होगा।

Comments

मैं अंतिम पैराग्राफ को नहीं समझता, क्या आप इसका उदाहरण दे सकते हैं कि "मूल संसाधन की तुलना में किसी अन्य चीज़ पर संशोधन को लागू करना संसाधन को कैसे अवैध कर सकता है", और यह कैसे एक ही संसाधन में कई बार परिवर्तन लागू करने से संबंधित है?

— रॉबिन ग्रीन

@ रॉबिनग्रीन: मान लें कि संसाधन एक्सएमएल में उस आवश्यकता के साथ दर्शाया गया है जिसमें सबसे अधिक एक <name>तत्व है। यदि PATCH <name>एक संसाधन को मूल रूप से एक नहीं जोड़ता है , तो PATCH को दो बार लागू करना (या इसे उस संसाधन पर लागू करना जिसमें पहले से ही शामिल है <name>) संसाधन को अमान्य बना देता है, क्योंकि इसमें अचानक दो <name>तत्व शामिल होंगे जिनकी अनुमति नहीं है ऐसे संसाधनों के लिए।

— बार्ट वैन इनगेन शेनौ

पहला उदाहरण जो आपने दिया है वह प्रासंगिक IMHO नहीं है क्योंकि यह वैसा ही है। DELETE के साथ उदाहरण, जो कि सबसे अच्छा है, पहला अनुरोध: संसाधन मौजूद है लेकिन हटा दिया गया है (रिटर्न 2xx), दूसरा अनुरोध: संसाधन मौजूद नहीं है और अनुरोध के बाद भी मौजूद नहीं है, 4xx देता है। सर्वर की स्थिति परिवर्तित नहीं हुई है, इस प्रकार यह सुविधा है। आपके उदाहरण में, पहला अनुरोध: बेनफ्रा से जोहोडे के लिए पाच, संसाधन का नाम बेन्फ्रा था, लेकिन अब जोहेडो (रिटर्न 2xx) है, दूसरा अनुरोध: बेनफ्रा से जोहोडे के लिए पाच, संसाधन का नाम जोहदो और फिर भी जोहडो (4xx लौटाता है)। तो यह नहीं दिखाता कि PATCH गैर-सरकारी हो सकती है।

— sp00m

यहाँ अधिक जानकारी: stackoverflow.com/q/4088350/1225328

— sp00m

Answer 2

मुझे लगता है कि स्पष्ट जवाब जब PATCH में नहीं बेरोजगार RFC 5789 से यह पैराग्राफ है:

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

जैसा कि RFC ने निर्दिष्ट किया है कि पैच में संसाधन में कुछ "सामान्य परिवर्तन" होते हैं, हमें केवल विशिष्ट क्षेत्र प्रतिस्थापन से परे देखना चाहिए। यदि संसाधन एक काउंटर के लिए है, तो पैच यह वेतन वृद्धि का अनुरोध कर सकता है, जो स्पष्ट रूप से idempotet नहीं है।

Answer 3

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

याद रखें PATCHअनुरोध केवल JSON ही नहीं, कई अलग-अलग स्वरूपों में संसाधनों को पैच करने के लिए इस्तेमाल किया जा सकता है।

यदि आप मर्जिंग नियमों को निर्धारित करते हैं, तो एक PATCHनिवेदन निष्प्राण हो सकता है ।

आदर्श उदाहरण:

// Original resource
{
  name: 'Tito',
  age: 32
}

// PATCH request
{
  age: 33
}

// New resource
{
  name: 'Tito',
  age: 33
}

गैर-बेरोजगार उदाहरण:

// Original resource
{
  name: 'Tito',
  age: 32
}

// PATCH request
{
  $increment: 'age'
}

// New resource
{
  name: 'Tito',
  age: 33
}

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

अब आप सोच रहे होंगे कि क्या इस तरह का बना हुआ सिंटैक्स मान्य है। मानकों के अनुसार , यह है:

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

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