बाकी, HTTP DELETE और पैरामीटर

Question

क्या HTTP DELETE अनुरोध में पैरामीटर प्रदान करने के बारे में कुछ भी गैर-रेस्टफुल है?

मेरा परिदृश्य यह है कि मैं मॉडलिंग कर रहा हूं "क्या आप सुनिश्चित हैं कि आप उसे हटाना चाहते हैं?" परिदृश्य। कुछ मामलों में, संसाधन की स्थिति बताती है कि अनुरोधित हटाएं अमान्य हो सकती हैं। आप शायद कुछ परिदृश्यों की स्वयं कल्पना कर सकते हैं जहाँ एक विलोपन की पुष्टि आवश्यक है

हमने जो समाधान अपनाया है, उसे हटाने के अनुरोध के लिए एक पैरामीटर पास करना है ताकि यह संकेत मिल सके कि हटाए जाने के साथ आगे बढ़ना ठीक है ("? Force_delete = true")

जैसे

DELETE http://server/resource/id?force_delete=true

मेरा मानना ​​है कि यह अभी भी बाकी है:

(ए) DELETE के शब्दार्थ को नहीं बदला जा रहा है - उपयोगकर्ता अभी भी एक सामान्य DELETE अनुरोध भेज सकता है लेकिन यह 409 के साथ विफल हो सकता है और प्रतिक्रिया का निकाय बताएगा कि क्यों। मेरा कहना है कि विफल हो सकता है क्योंकि (कुछ कारणों से समझाने लायक नहीं) कुछ अवसरों पर उपयोगकर्ता को संकेत देने का कोई कारण नहीं है।

(ख) रॉय के शोध में ऐसा कुछ भी नहीं है जिससे यह पता चल सके कि यह रेस्ट की भावना के खिलाफ है - ऐसा क्यों होगा क्योंकि HTTP केवल REST का कार्यान्वयन है इसलिए HTTP पैरामीटर्स को क्यों पास किया जाएगा

क्या कोई मुझे निश्चित कथन पर इंगित कर सकता है कि नाखूनों का कारण यह क्यों नहीं है?

संबंधित प्रश्न पर, यदि उपयोगकर्ता बल_डेली निर्दिष्ट नहीं करता है तो मैं वापस लौट रहा हूं 409 Conflict- क्या यह सबसे उपयुक्त प्रतिक्रिया कोड है?

ऊपर का पालन करें

कुछ और शोधों के बाद, मुझे लगता है कि DELETE में मापदंडों को जोड़ने से कई सिद्धांतों का उल्लंघन हो सकता है।

पहला यह है कि कार्यान्वयन संभवतः "यूनिफ़ॉर्म इंटरफ़ेस" का उल्लंघन करता है ( रॉय के शोध प्रबंध की धारा 5.1.5 देखें)

'Force_delete' जोड़कर हम पहले से ही परिभाषित DELETE पद्धति पर एक अतिरिक्त बाधा जोड़ रहे हैं। यह अड़चन हमारे लिए ही सार्थक है।

आप यह भी तर्क दे सकते हैं कि यह "5.1.2 क्लाइंट-सर्वर" का उल्लंघन करता है क्योंकि पुष्टि संवाद वास्तव में एक यूआई चिंता है और फिर से सभी ग्राहक विलोपन की पुष्टि नहीं करना चाहेंगे।

किसी को सुझाव?

Comments

रॉय के शोध प्रबंध के लिए आपके यूआरएल में एक ")" है, जो 404 का कारण बनता है । ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm कार्य करता है।

— न्यूक्लियरपेय

Answer 1

नहीं, यह RESTful नहीं है। force_deleteURI में एक क्रिया ( ) क्यों की जानी चाहिए, इसका एकमात्र कारण यह है कि यदि आपको PUT / DELETE पद्धतियाँ उपलब्ध नहीं हैं तो आपको GET / POST विधियों को ओवरलोड करना होगा। DELETE पद्धति के आपके उपयोग को देखते हुए, यह मामला नहीं है।

HTTP त्रुटि कोड 409/Conflictका उपयोग उन स्थितियों के लिए किया जाना चाहिए जहां कोई विरोध है जो ऑपरेशन को निष्पादित करने के लिए Restful सेवा को रोकता है, लेकिन अभी भी एक मौका है कि उपयोगकर्ता स्वयं विरोध को हल करने में सक्षम हो सकता है। एक पूर्व-विलोपन की पुष्टि (जहां वास्तविक संघर्ष नहीं हैं जो विलोपन को रोकेंगे) प्रति संघर्ष नहीं है, क्योंकि कुछ भी एपीआई को अनुरोधित ऑपरेशन करने से रोकता है।

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

UI में यह करने के लिए दो उदाहरण होंगे:

• प्री-एचटीएमएल 5 : * उपयोगकर्ता को एक जेएस पुष्टिकरण संवाद दिखाता है, और अनुरोध केवल तभी भेजता है जब उपयोगकर्ता इसकी पुष्टि करता है
• HTML5 : * एक्शन फॉर्म के साथ DELETE का उपयोग करें जहाँ फॉर्म में केवल "कन्फर्म" और "कैंसल" बटन होंगे ("कन्फर्म" सबमिट बटन होगा)

(*) कृपया ध्यान दें कि 5 से पहले वाले HTML संस्करण मूल रूप से PUT और DELETE HTTP विधियों का समर्थन नहीं करते हैं, हालाँकि अधिकांश आधुनिक ब्राउज़र AJAX कॉल के माध्यम से इन दोनों विधियों को कर सकते हैं। देखें इस सूत्र पार ब्राउज़र समर्थन के बारे में जानकारी के लिए।

---

अद्यतन (अतिरिक्त जांच और चर्चा के आधार पर):

परिदृश्य जहाँ सेवा की आवश्यकता होती है force_delete=trueध्वज को मौजूद होना चाहिए रॉय फील्डिंग के शोध प्रबंध में परिभाषित समान इंटरफ़ेस का उल्लंघन करता है । इसके अलावा, HTTP RFC के अनुसार , DELETE पद्धति को मूल सर्वर (क्लाइंट) पर ओवरराइड किया जा सकता है, जिसका अर्थ है कि यह लक्ष्य सर्वर (सेवा) पर नहीं किया गया है।

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

Comments

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

— डारेल मिलर

@ विवाद: (imho) यह HTTP मानकों के अनुसार प्रदर्शन नहीं कर DELETE विधि द्वारा एकसमान इंटरफ़ेस का उल्लंघन करता है। REST क्लाइंट पर विचार करें जो एक मानक REST सेवा मानता है - ग्राहक को यह कैसे पता चलेगा कि सेवा को कैसे जोड़ना होगा force_delete=true? HTTP RFC के अनुसार, DELETE पद्धति मूल सर्वर (क्लाइंट) पर निर्भर हो सकती है, जिसका अर्थ है कि यह लक्ष्य सर्वर (सेवा) पर नहीं किया गया है। तो मेरी समझ यह है कि एक बार सेवा को DELETE अनुरोध प्राप्त होने के बाद, उसे किसी भी पुष्टि की आवश्यकता के बिना प्रक्रिया करनी चाहिए (भले ही सेवा वास्तव में ऑपरेशन करती हो)।

— माइक

@ क्रिस, अपने दूसरे बिंदु पर: हाँ, यह मेरी समझ है, यानी कि राज्य एक वास्तविक संघर्ष का सुझाव देता है और पुष्टि की आवश्यकता नहीं। मैंने केवल उस अपडेट पर ध्यान दिया है जो आपने अपने प्रश्न में किया था, और मैं सहमत हूं - जब मैं इसे स्वयं देख रहा था, तो मैं एक ही निष्कर्ष पर आया था (कि यह एकसमान इंटरफ़ेस का उल्लंघन करता है, और यह पुष्टि क्लाइंट / यूआई पर की जानी चाहिए) की ओर)। मैं यहाँ एक बहुत ही रोचक सूत्र पर भी चला, यह मदद कर सकता है: mail-archive.com/[e-mail]/msg13578.html

— माइक

@MicE काफी हद तक मैं आपसे सहमत हूं कि यह इस परिदृश्य को संभालने का आदर्श तरीका नहीं है। मैं सिर्फ "इट्स रेस्टफुल" लेबल के बारे में कुछ नहीं समझ रहा हूँ। यहां कुछ समय के लिए उस वाक्यांश को सब कुछ फेंक दिया गया था। हालांकि, एक मीडिया प्रकार के लिए नियमों को परिभाषित करना संभव होगा जो कहते हैं कि यदि आप एक संसाधन का उपयोग करने का प्रयास करते हैं और आपको एक त्रुटि मिलती है (मैं कहूंगा कि 403 निषिद्ध 409 से बेहतर होगा), तो ग्राहक को संबंधित संसाधन पर DELETE का प्रयास करना चाहिए एक "force_delete = true" पर काम करके। एक तरह से यह प्राधिकरण जैसा है। GET करें, 401 प्राप्त करें, फिर से हेडर लगाएं और फिर से प्राप्त करें।

— डारेल मिलर

@ विवाद: यह एक बहुत अच्छी बात है, धन्यवाद। और मैंने देखा है कि लोग खुद को RESTful लेबल नहीं फेंकते हैं । यह मामला हो सकता है कि आजकल सेवाओं और वेब अनुप्रयोगों के बीच बाधा बहुत धूमिल हो रही है, इसलिए लोगों का एक सेट इसे शुद्ध-सेवा के दृष्टिकोण से देख सकता है, जबकि अन्य इसे मिश्रित एप्लिकेशन / सेवा के दृष्टिकोण से देखते हैं। मेरा मानना ​​है कि पुष्टि करने के लिए वास्तविक सवाल कहां है कि यह कैसे चलन में है। @ क्रिस: अपडेट किया गया - बहुत दिलचस्प विषय और चर्चा के लिए धन्यवाद सर!

— 18

Answer 2

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

बल निर्दिष्ट करने से क्या यह सच है कि क्या यह एक प्रोग्राम एपीआई है? यदि कोई व्यक्ति इस संसाधन को हटाने के लिए एक स्क्रिप्ट लिख रहा था, तो क्या आप उन्हें बलपूर्वक निर्दिष्ट करने के लिए बाध्य करना चाहेंगे = वास्तव में संसाधन को हटाने के लिए सही?

Comments

आपकी प्रतिक्रिया का पहला पैराग्राफ आपकी राय है और मैं इस बात का सम्मान करता हूं लेकिन आपने साहित्य में किसी ऐसी चीज़ की ओर इशारा नहीं किया है जो यूआरआई के उपयोग को इस तरह मना करती है - यह अभी भी संसाधन की पहचान करता है और सबसे उपयुक्त HTTP क्रिया का उपयोग किया जा रहा है। आपके सवालों के जवाब में; हाँ, यह अभी भी समझ में आता है (मेरी राय में)। मैं 409 प्रतिक्रिया का सम्मान करने के लिए एक स्क्रिप्ट (शायद CURL पर आधारित) की उम्मीद करूंगा और उपयोगकर्ता को सुझाव दूंगा कि कैसे अनुरोध नाराज हो सकता है - यह सब मेरी प्रतिक्रिया निकाय पर आधारित है

— क्रिस मैककॉले

वेब एपीआई को प्रोग्राम के एपीआई से तुलना करने के बारे में अच्छी बात है। यह अक्सर यह पता लगाने का एक अच्छा तरीका है कि क्या API RESTful है या नहीं।

— लौरेंत

Answer 3

यह एक पुराना सवाल है, लेकिन यहां कुछ टिप्पणियां हैं ...

1. SQL में, DELETE कमांड एक पैरामीटर "CASCADE" को स्वीकार करता है, जो आपको यह निर्दिष्ट करने की अनुमति देता है कि निर्भर वस्तुओं को भी हटा दिया जाना चाहिए। यह एक DELETE पैरामीटर का एक उदाहरण है जो समझ में आता है, लेकिन 'मैन आरएम' दूसरों को प्रदान कर सकता है। पैरामीटर के बिना ये मामले संभवतः REST / HTTP में कैसे लागू किए जाएंगे?
2. @ जान, यह एक अच्छी तरह से स्थापित कन्वेंशन प्रतीत होता है कि URL का पथ भाग एक संसाधन की पहचान करता है, जबकि क्वेरिस्ट्रिंग नहीं करता है (कम से कम जरूरी नहीं)। उदाहरण लाजिमी है: एक ही संसाधन प्राप्त करना लेकिन एक अलग प्रारूप में, एक संसाधन के विशिष्ट क्षेत्र प्राप्त करना, आदि। यदि हम क्वेरिस्ट्रिंग को संसाधन पहचानकर्ता के हिस्से के रूप में मानते हैं, तो "एक ही संसाधन के विभिन्न विचारों" की अवधारणा का होना असंभव है HTTP कंटेंट वार्ता (जो कई कारणों से अवांछनीय हो सकती है) जैसे गैर-रिस्टफुल मैकेनिज्म की ओर रुख किए बिना।

Comments

इस बातचीत में जोड़ने के लिए धन्यवाद, भले ही यह बातचीत के बहुत साल से न हो।

— सिल्वियोट

Answer 4

एलेक्स के जवाब के अलावा:

ध्यान दें कि http: // सर्वर / संसाधन / आईडी? Force_delete = सच http: // सर्वर / संसाधन / आईडी से अलग संसाधन की पहचान करता है । उदाहरण के लिए, यह एक बड़ा अंतर है कि क्या आप / ग्राहकों को हटाते हैं? स्थिति = पुराना या / ग्राहक /।

जनवरी

Comments

मैं असहमत हूं, मैं एक ही संसाधन की पहचान करने के लिए कई यूआरआई प्रदान करने के लिए स्वतंत्र हूं।

— क्रिस मैकॉले

हां - हर कोई एक गड़बड़ बनाने के लिए स्वतंत्र है :-)

— Jan Algermissen

विहित यूआरआई का संकेत इससे मदद कर सकता है: googlewebmastercentral.blogspot.com/2009/02/…

— माइक

@ क्रिस केवल एक यूआरआई होना चाहिए जो एक संसाधन का प्रतिनिधित्व लौटाता है। अन्य यूआरआई एक ही अवधारणा को संदर्भित कर सकते हैं लेकिन एक GET कर 303 See अन्य को वापस करना चाहिए। और इस पर स्पष्ट आपत्ति का मुकाबला करने के लिए, /foo.xml और /foo.json दो अलग-अलग संसाधन हैं।

— डारेल मिलर

@ डारेल - सहमत हैं, लेकिन प्रारूप यहां कोई समस्या नहीं है। इसके अलावा .format रेल और अन्य चौखटे में एक सम्मेलन है जो REST का हिस्सा नहीं है - आपको इसे पूरी तरह से लागू करने के लिए MIME या माइक्रोफ़ॉर्मेट्स के साथ HTTP में सामग्री वार्ता का उपयोग करना चाहिए।

— क्रिस मैकॉले