तो, यह देखते हुए कि Http में DELETE क्रिया सुस्पष्ट है, जब मैं निम्नलिखित अनुरोध जारी करता हूं, तो दूसरी (या तीसरी, या चौथी, आदि ...) क्या होनी चाहिए?
DELETE /person/123
पहली बार, संसाधन हटा दिया गया है और मैं 204 (सफल, कोई सामग्री नहीं) लौटाता हूं। क्या मुझे बाद की कॉल या 404 (नहीं मिला) पर 204 लौटाना चाहिए?
जवाबों:
जैसा कि एक स्टेटलेस सिस्टम में HTTP अनुरोध स्वतंत्र होना चाहिए, एक अनुरोध के परिणाम पिछले अनुरोध पर निर्भर नहीं होना चाहिए। विचार करें कि यदि दो उपयोगकर्ताओं ने एक ही संसाधन पर एक साथ DELETE किया तो क्या होना चाहिए। यह 404 पाने के लिए दूसरे अनुरोध के लिए समझ में आता है। यदि एक उपयोगकर्ता दो अनुरोध करता है, तो यह सच होना चाहिए।
मैं अनुमान लगा रहा हूं कि दो अलग-अलग प्रतिक्रियाओं को डिलीट करने के बाद आपको कुछ भी अप्रिय नहीं लगता। मुझे एक ही स्थिति में सिस्टम को छोड़ने के रूप में सुखद अनुरोधों के बारे में सोचना उपयोगी लगता है, जरूरी नहीं कि एक ही प्रतिक्रिया हो। इस बात की परवाह किए बिना कि क्या आप किसी मौजूदा संसाधन को प्राप्त करते हैं, या मौजूद संसाधन का उपयोग करने का प्रयास करते हैं, सर्वर संसाधन स्थिति समान है।
rm। rmयदि यह मौजूद नहीं है तो एक त्रुटि देता है। tools.ietf.org/html/rfc7231#section-4.3.5
रेस्टफुल वेब सर्विसेज कुकबुक इसके लिए एक बेहतरीन संसाधन है। संयोग से, इसका Google पूर्वावलोकन DELETE (पृष्ठ 11) के बारे में पृष्ठ दिखाता है:
DELETE विधि उदासीन है। इसका मतलब यह है कि सर्वर को प्रतिक्रिया कोड 200 (ओके) वापस करना होगा, भले ही सर्वर ने पिछले अनुरोध में संसाधन हटा दिया हो। लेकिन व्यवहार में, DELETE को एक आदर्श ऑपरेशन के रूप में लागू करने के लिए सर्वर को सभी हटाए गए संसाधनों का ट्रैक रखने की आवश्यकता होती है। अन्यथा, यह 404 (नहीं मिला) वापस कर सकता है।
मैं इस बात से सहमत हूं कि वर्तमान चुने गए उत्तर ने क्या कहा है, कि 2nd (और 3rd, 4th, ...) DELETE को 404 मिलना चाहिए । और, मैंने देखा कि जवाब में 143 वोट हैं, लेकिन एक विपरीत टिप्पणी भी है जिसमें 54 वोट हैं, इसलिए समुदाय को लगभग 3: 1 अनुपात में 2 शिविरों में विभाजित किया गया है। इस लंबे समय की बहस को निपटाने के लिए यहां अधिक जानकारी है।
सबसे पहले, चलो शुरू नहीं करते हैं कि "मैं" क्या सोचता है, क्या "आप" सोचते हैं, या फिर कोई अन्य पुस्तक लेखक क्या सोचता है। आइए HTTP स्पेक्स यानी RFC 7231 से शुरुआत करें।
DELETE /some/resource/which/does/not/exist404 में परिणाम होना चाहिए। फिर, DELETE /some/resource/which/happened/to/be/removed/by/someone/else/five/days/agoएक 404 भी वापस कर सकता है। फिर, DELETE /some/resource/i/deleted/five/seconds/agoकोई अलग क्यों होना चाहिए ? "लेकिन कैसे के बारे में idempotency ?!", मैं सुन सकता हूँ कि आप चिल्ला रहे हैं। रुको, हम उस में शामिल होने वाले हैं।ऐतिहासिक रूप से, 1999 में प्रकाशित RFC 2616, सबसे अधिक संदर्भित HTTP 1.1 चश्मा था। दुर्भाग्य से इसका वर्णन बेमेलता पर अस्पष्ट था , जो इन सभी बहसों के लिए जगह छोड़ देता है। लेकिन उस चश्मा को RFC 7231 द्वारा अधिगृहीत किया गया है। RFC 7231 से उद्धृत , खंड 4.2.2 सुस्पष्ट तरीके , जोर मेरा:
एक अनुरोध विधि को "निष्प्राण" माना जाता है, यदि उस विधि के साथ कई समान अनुरोधों के उद्देश्य पर एक ही अनुरोध के लिए प्रभाव के समान है। इस विनिर्देशन द्वारा परिभाषित अनुरोध विधियों में से PUT, DELETE , और सुरक्षित अनुरोध विधियाँ उदासीन हैं ।
तो, यह ऐनक में लिखा है, idempotency सर्वर पर प्रभाव के बारे में है। पहला DELETE 204 लौटा रहा है और फिर बाद में DELETE 404 लौटा रहा है, इस तरह के अलग-अलग स्टेटस कोड DELETE को नॉन-इम्पोटेंट नहीं बनाते हैं। 204 के बाद के रिटर्न को सही ठहराने के लिए इस तर्क का उपयोग करना, बस अप्रासंगिक है।
ठीक है तो यह बेवकूफी के बारे में नहीं है। लेकिन फिर एक अनुवर्ती सवाल यह हो सकता है कि अगर हम अभी भी बाद के DELETE में 204 का उपयोग करना चाहते हैं, तो क्या होगा? ठीक है न?
अच्छा प्रश्न। प्रेरणा समझ में आता है: क्लाइंट को अभी भी त्रुटि से निपटने के बारे में चिंता किए बिना, अपने इच्छित परिणाम तक पहुंचने की अनुमति देता है। मैं कहूंगा, 204 को बाद के DELETE में लौटाना, काफी हद तक हानिरहित सर्वर-साइड "व्हाइट झूठ" है, जो क्लाइंट-साइड तुरंत एक अंतर नहीं बताएगा। यही कारण है कि वहाँ ~ 25% लोग कर रहे हैं कि जंगली और यह प्रतीत होता है अभी भी काम करता है। बस ध्यान रखें कि, इस तरह के झूठ को शब्दार्थ रूप से अजीब माना जा सकता है, क्योंकि GET /non-exist404 रिटर्न DELETE /non-existदेता है, लेकिन 204 देता है, उस बिंदु पर ग्राहक यह पता लगाएगा कि आपकी सेवा पूरी तरह से खंड 6.5.4 404 का अनुपालन नहीं करती है ।
लेकिन मैं यह बताना चाहता हूं कि, RFC 7231 द्वारा संकेतित तरीका, यानी बाद में DELETE में 404 वापस करना, पहली जगह में एक मुद्दा नहीं होना चाहिए। 3x अधिक डेवलपर्स ने ऐसा करने के लिए चुना, और क्या आपने कभी किसी बड़ी घटना के बारे में सुना या किसी ग्राहक द्वारा 404 को संभालने में सक्षम नहीं होने के कारण शिकायत की? संभवतः, नहीं, और ऐसा इसलिए है, क्योंकि कोई भी सभ्य क्लाइंट जो HTTP DELETE (या उस मामले के लिए किसी भी HTTP विधि) को लागू करता है, नेत्रहीन यह नहीं मानेंगे कि परिणाम हमेशा 2xx सफल होगा। और फिर, एक बार डेवलपर ने त्रुटि से निपटने पर विचार करना शुरू कर दिया, 404 नॉट फाउंड पाया गया जो पहली त्रुटियों में से एक होगा जो मन में आता है। उस बिंदु पर, वह / वह शायद एक निष्कर्ष निकालेगी कि, यह एक 40% त्रुटि को अनदेखा करने के लिए HTTP DELETE ऑपरेशन के लिए शब्दार्थ रूप से सुरक्षित है। और उन्होंने ऐसा किया।
समस्या सुलझ गयी।
पहला DELETE : 200 या 204।
बाद में DELETEs : 200 या 204।
तर्क : DELETE को बेरोजगार होना चाहिए। यदि आप एक दूसरे DELETE पर 404 लौटाते हैं, तो आपकी प्रतिक्रिया एक सफलता कोड से एक त्रुटि कोड में बदल रही है। ग्राहक कार्यक्रम DELETE विफल होने की धारणा के आधार पर गलत कार्य कर सकता है।
उदाहरण :
इस दृष्टिकोण के उपयोग को स्पष्ट करने के लिए, पेपाल के लिए HTTP एपीआई शैली गाइड में निम्नलिखित दिशानिर्देश हैं:
DELETE: यह विधि SHOULD रिटर्न स्टेटस कोड 204 है क्योंकि ज्यादातर मामलों में किसी भी सामग्री को वापस करने की कोई आवश्यकता नहीं है क्योंकि अनुरोध एक संसाधन को हटाने के लिए है और इसे सफलतापूर्वक हटा दिया गया था।
जैसे ही DELETE मेथड जरूरी है, वैसे ही, यह अभी भी 204 है, भले ही संसाधन पहले ही हटा दिया गया हो। आमतौर पर एपीआई उपभोक्ता परवाह नहीं करता है अगर संसाधन को इस ऑपरेशन के हिस्से के रूप में हटा दिया गया था, या पहले। यही कारण है कि 404 के बजाय 204 को वापस किया जाना चाहिए।