HTTP DELETE के संदर्भ में idempotency देखने का सही तरीका क्या है?

Question

मैंने हाल ही में HTTP 1.1 विनिर्देश पढ़ने और इसे आरईएसटी से संबंधित बहुत समय बिताया है। मैंने पाया है कि इसकी "बेवकूफता" और सुरक्षा के संबंध में HTTP DELETE विधि की दो व्याख्याएं हैं। यहाँ दो शिविरों हैं:

1. आप हटाना HTTP के साथ एक संसाधन को हटाते हैं, और यह सफल होता है (200 ठीक), और फिर आप समय की है कि संसाधन एन संख्या को हटाने का प्रयास है, तो आप वापस मिलना चाहिए एक सफलता संदेश (200 ओके) उन सभी में से प्रत्येक के लिए कॉल हटाएं। यह इसकी "बेवकूफता" है।

2. यदि आप HTTP DELETE के साथ संसाधन हटाते हैं, और यह सफल होता है (200 ठीक है), और फिर आप उस संसाधन को फिर से हटाने का प्रयास करते हैं, तो आपको एक त्रुटि संदेश (410 चला गया) वापस लेना चाहिए क्योंकि संसाधन हटा दिया गया था।

विनिर्देश DELETE कहते हैं, idempotent है यकीन है, लेकिन यह भी कहता है कि idempotent घटनाओं के दृश्यों अभी भी साइड इफेक्ट का उत्पादन कर सकते हैं। मुझे सच में लगता है कि दूसरा शिविर सही है, और पहला भ्रामक है। ग्राहकों को यह सोचने की अनुमति देकर हमने "सुरक्षा" क्या पेश की है कि वे पहले से हटाए गए संसाधन को हटाने का कारण थे?

इस विषय पर कई लेखकों समेत पहले शिविर में बहुत से लोग हैं, इसलिए मैं यह जांचना चाहता था कि भावनाओं के अलावा कुछ अनिवार्य कारण हैं जो लोगों को पहले शिविर में ले जाते हैं।

Answer 1

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

मेरी राय में, बाद में DELETE अनुरोध को एक त्रुटि वापस करनी चाहिए - यह अभी भी बेवकूफ है क्योंकि सर्वर की स्थिति वही है जैसे केवल एक ही अनुरोध अनुरोध किया गया था। फिर फिर से 200 ओके स्थिति को वापस करना ठीक है - मुझे नहीं लगता कि idempotent को के बाद के DELETE अनुरोधों के लिए त्रुटि कोड लौटने की आवश्यकता है - यह केवल त्रुटि स्थिति को वापस करने के लिए मुझे अधिक समझ में आता है।

Answer 2

@MichaelBurr idempotency और दुष्प्रभावों के बारे में सही है।

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

idempotent समारोह के लिए:

delete(client_state) -> client_state - {item} 
delete(delete(client_state)) -> client_state - {item} 
delete(client_state) = delete(delete(client_state)) 

इस idempotency गारंटी करने के लिए सबसे अच्छा तरीका है अगर सर्वर की प्रतिक्रिया समान है, कि ग्राहक के राज्य को तोड़ने के लिए idempotency वहाँ के लिए गैर हो रहा है के लिए एक ही रास्ता का मतलब ग्राहक की प्रतिक्रिया के संचालन में निर्धारकता या दुष्प्रभाव (जो शायद प्रतिक्रिया को संभालने के गलत कार्यान्वयन को इंगित करता है)।

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

HTTP अनुरोध तरीकों को दूर करना शामिल है, तो समारोह के समान हो सकता है

delete(client_state) = send_delete(client_state) -> receive_delete(client_state) 
               -> respond_to_delete(informative_state) 
               -> handle_response(informative_state) 
               -> client_state - {item} 

Answer 3

Wikipedia एक ऑपरेशन के रूप में परिभाषित करता है Idempotence:

प्रारंभिक आवेदन परे परिणाम बदले बिना कई बार लागू किया जा सकता।

ध्यान दें कि वे ऑपरेशन के result के बारे में बात करते हैं। मेरे लिए, इसमें दोनों सर्वर राज्य और प्रतिक्रिया कोड शामिल हैं।

HTTP विनिर्देश इस मामले पर थोड़ा अधिक अस्पष्ट है। यह defines it निर्दिष्ट करता है कि HTTP विधियां Idempotent हैं:

यदि एकाधिक समान अनुरोधों का इच्छित प्रभाव एक ही अनुरोध के समान है।

आप विकिपीडिया परिभाषा effectresult के रूप में व्याख्या तो वे एक ही मतलब है। किसी भी मामले में, मैं ग्राहकों को यह बताने के व्यावहारिक लाभ पर सवाल करता हूं कि संसाधन पहले ही हटा दिया गया है।

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

दोहराने के लिए: आपको एक ही रिटर्न कोड वापस करना चाहिए, चाहे संसाधन अभी हटा दिया गया हो, पिछले अनुरोध से हटा दिया गया था, या कभी भी अस्तित्व में नहीं था।