PUT और DELETE HTTP अनुरोध विधियों की उपयोगिता क्या है?

Question

मैंने इस बारे में बहुत कुछ पढ़ा है लेकिन इस विषय पर निष्कर्ष निकालने में सक्षम नहीं हूं।

लेकिन मैंने कभी PUT या DELETE HTTP अनुरोध विधियों का उपयोग नहीं किया है। मेरी प्रवृत्ति GET का उपयोग करने के लिए है जब सिस्टम (मेरा एप्लिकेशन या वेबसाइट) की स्टेट प्रभावित नहीं हो सकती है (जैसे उत्पाद लिस्टिंग) और POST का उपयोग करने के लिए जब यह प्रभावित होता है (रखा गया आदेश)। क्या यह पर्याप्त नहीं है या मैं कुछ याद कर रहा हूँ?

Comments

PUT / DELETE कोड करना आसान है, लेकिन सेटअप करने के लिए कठिन है (सुरक्षा बुद्धिमानी - vhost / apache निर्देशिका)। मेरी विनम्र राय ... आप उन लोगों के बिना रह सकते हैं।

— नाज़्ज़रो

@Najzero हाँ, मैं उनके बिना बहुत खुश हूँ :) लेकिन उन्हें वहाँ क्यों हैं इस पर कुछ जवाब चाहिए? कुछ सामान पढ़ा है, लेकिन इसे

— कॉपी

Answer 1

DELETE अनुरोध संसाधन को हटाने के लिए है:

DELETE विधि अनुरोध करती है कि मूल सर्वर अनुरोध-URI द्वारा पहचाने गए संसाधन को हटा दें। इस विधि को मूल सर्वर पर मानव हस्तक्षेप (या अन्य साधनों) द्वारा ओवरराइड किया जाना चाहिए। क्लाइंट को गारंटी नहीं दी जा सकती है कि ऑपरेशन किया गया है, भले ही स्थिति कोड मूल सर्वर से लौटा हो, यह इंगित करता है कि कार्रवाई पूरी हो चुकी है ...

PUT सर्वर पर संसाधन डालने या अपडेट करने के लिए है:

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

पूर्ण विनिर्देश यात्रा के लिए:

• http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

चूंकि वर्तमान ब्राउज़र दुर्भाग्य से HTML रूपों में POST और GET के अलावा किसी अन्य क्रिया का समर्थन नहीं करते हैं , आप आमतौर पर HTTP का उपयोग उनके साथ पूर्ण सीमा तक नहीं कर सकते हैं (आप अभी भी जावास्क्रिप्ट के माध्यम से उनके प्रस्तुतिकरण को हाईजैक कर सकते हैं)। HTML रूपों में इन तरीकों के लिए समर्थन की अनुपस्थिति उदाहरण के लिए, क्रियाओं वाले URI के लिए नेतृत्व किया

POST http://example.com/order/1/delete

या इससे भी बदतर

POST http://example.com/deleteOrder/id/1

प्रभावी ढंग से HTTP पर CRUD शब्दार्थ को सुरंग बनाना। लेकिन क्रियाएं कभी यूआरआई का हिस्सा नहीं थीं। इसके बजाय HTTP पहले से ही HTTP विधियों के माध्यम से एक संसाधन (जैसे एक आदेश) CRUD को तंत्र और शब्दार्थ प्रदान करता है। HTTP एक प्रोटोकॉल है और सिर्फ कुछ डेटा टनलिंग सेवा नहीं है।

इसलिए वेबसर्वर पर एक संसाधन को हटाने के लिए, आप कॉल करेंगे

DELETE http://example.com/order/1

और इसे अपडेट करने के लिए आप कॉल करेंगे

PUT http://example.com/order/1

और तब लागू करने के लिए वेबसर्वर के लिए PUT निकाय में अद्यतन संसाधन प्रतिनिधित्व प्रदान करें।

इसलिए, यदि आप REST API के लिए किसी प्रकार का क्लाइंट बना रहे हैं, तो आप संभवतः इसे PUT और DELETE अनुरोध भेजेंगे। यह एक ब्राउज़र के अंदर निर्मित क्लाइंट हो सकता है, उदाहरण के लिए जावास्क्रिप्ट के माध्यम से अनुरोध भेजना या यह सर्वर पर चलने वाला कुछ उपकरण हो सकता है, आदि।

कुछ और विवरणों के लिए देखें:

• http://martinfowler.com/articles/richardsonMaturityModel.html
• क्या अधिकांश वेब ब्राउज़र में PUT, DELETE, HEAD, आदि विधियाँ उपलब्ध हैं?
• HTML फॉर्म में कोई PUT और DELETE तरीके क्यों नहीं हैं
• क्या PUT और DELETE का उपयोग रूपों में किया जाना चाहिए?
• http://amundsen.com/examples/put-delete-forms/
• http://www.quora.com/HTTP/Why-are-PUT-and-DELETE-no-longer-supported-in-HTML5-forms

Comments

ब्राउज़र्स PUT और DELETE को जावास्क्रिप्ट के साथ भेज सकते हैं !

— जो

@ हाँ, लेकिन HTML फ़ॉर्म विधियाँ नहीं हैं। और जब तक यह बॉक्स से बाहर समर्थित नहीं है, आपको इसे काम करने के लिए हुप्स से गुजरना होगा। यह ब्राउज़र विक्रेताओं की प्रमुख विफलताओं में से एक है।

— गॉर्डन १

बेशक वे नहीं, फॉर्म POST और GET के लिए डिज़ाइन किए गए हैं। यह डिज़ाइन HTML में है। यह कहना सही नहीं है कि हालांकि PUT और DELETE समर्थित नहीं हैं। ब्राउज़र HTML और HTTP को लागू करते हैं।

— जो

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

— गॉर्डन

जब तक आप कुछ HTML नहीं लिखते, ब्राउज़र एक खाली पृष्ठ प्रदर्शित करता है। हां, शायद हमें असहमत होना पड़ेगा। असहमत होना ठीक है!

— जो

Answer 2

HTTP रिक्वेस्ट वर्ब जैसे कि GET, POST, DELETE, PUT आदि का उपयोग करना ... आपको Restful वेब एप्लिकेशन बनाने में सक्षम बनाता है। इसके बारे में यहां पढ़ें: http://en.wikipedia.org/wiki/Representational_state_transfer

इससे लाभ देखने का सबसे आसान तरीका इस उदाहरण को देखना है। हर MVC फ्रेमवर्क में Router/Dispatcherएक्शनकंट्रोलर्स के लिए यूआरएल मैप-एस होता है। तो URL इस तरह: /blog/article/1invoke blogController::articleAction($id); Now यह राउटर केवल URL से वाकिफ है/blog/article/1/

लेकिन अगर उस राउटर को सिर्फ URL के बजाय पूरे HTTP रिक्वेस्ट ऑब्जेक्ट के बारे में पता होगा, तो वह HTTP रिक्वेस्ट वर्ब (GET, POST, PUT, DELETE ...) तक पहुंच सकता है, और वर्तमान HTTP रिक्वेस्ट के बारे में कई अन्य उपयोगी चीजें।

यह आपको एप्लिकेशन को कॉन्फ़िगर करने में सक्षम करेगा ताकि यह एक ही URL को स्वीकार कर सके और HTTP रिक्वेस्ट क्रिया के आधार पर इसे विभिन्न एक्शनकंट्रोलर को मैप कर सके।

उदाहरण के लिए:

यदि आप लेख 1 को पुनः प्राप्त करना चाहते हैं, तो आप ऐसा कर सकते हैं:

GET /blog/article/1 HTTP/1.1

लेकिन यदि आप लेख 1 को हटाना चाहते हैं तो आप ऐसा करेंगे:

DELETE /blog/article/1 HTTP/1.1

ध्यान दें कि दोनों HTTP अनुरोधों में एक ही URI, / ब्लॉग / लेख / 1 है, केवल अंतर HTTP अनुरोध क्रिया है। और उस क्रिया के आधार पर आपका राउटर विभिन्न एक्शनकंट्रोलर को कॉल कर सकता है। यह आपको स्वच्छ URL-s बनाने में सक्षम बनाता है।

यह दो लेख पढ़ें, वे आपकी मदद कर सकते हैं:

सिम्फनी 2 - एचटीटीपी फंडामेंटल

सिम्फनी 2 - रूटिंग

ये लेख Symfony 2 ढांचे के बारे में हैं, लेकिन वे यह पता लगाने में आपकी मदद कर सकते हैं कि HTTP अनुरोध और प्रतिक्रियाएं कैसे काम करती हैं।

उम्मीद है की यह मदद करेगा!

Comments

भले ही मैं उनमें से एक दोस्त नहीं हूँ, अच्छी तरह से समझाया; +1 ;-)

— Najzero

यह उत्तर HTTP क्रियाओं के महत्व और वास्तव में उपयोगी सेवाओं और उनके लाभों के अनुरूप रखने के लिए सबसे अच्छा वर्णन करता है। यदि आप HTTP DELETE कहने के लिए उपयोग नहीं करते हैं, तो आपके पास नियंत्रक में 1 (2) POST क्रियाएँ हो सकती हैं: 1 के लिए Createऔर 1 के लिए Delete। यदि आप ऐसा करते हैं, तो आपकी अगली खोज " एक ही नियंत्रक में कई पोस्ट क्रियाएं कैसे करें " के लिए होगी : पी। ऐसा नहीं है कि यह भयानक है, लेकिन आप क्रिया के माध्यम से एक अद्वितीय संसाधन को लागू करने की क्षमता को ढीला कर देते हैं क्योंकि URI में कार्रवाई नाम को स्पष्ट रूप से प्रदान करने का विरोध किया गया है।

— atconway

Answer 3

यद्यपि मैं लोकप्रिय नहीं होने का जोखिम उठाता हूं लेकिन मैं कहता हूं कि वे आजकल उपयोगी नहीं हैं ।

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

चीजें विकसित हुईं और URL वर्चुअल हो गए ( उदाहरण के लिए url पुनर्लेखन देखें ), जिससे संसाधन वास्तविक फ़ोल्डर / सबफ़ोल्डर / फ़ाइल का प्रारंभिक अर्थ खो देते हैं और इसलिए, CRUD कार्रवाई क्रिया HTTP प्रोटोकॉल विधियों (GET, POST, PUT / PUTCH, DELETE) द्वारा खो दिया गया है। ।

आइए एक उदाहरण लेते हैं:

• / एपीआई / इकाई / सूची / {आईडी} बनाम जीईटी / एपीआई / इकाई / {आईडी}
• / एपीआई / इकाई / जोड़ने / {आईडी} बनाम पोस्ट / एपीआई / इकाई
• / एपीआई / इकाई / संपादित / {आईडी} बनाम पूट / एपीआई / इकाई / {आईडी}
• / एपीआई / इकाई / डिलीट / {आईडी} बनाम DELETE / एपीआई / इकाई / {आईडी}

बाईं ओर HTTP विधि नहीं लिखी गई है, अनिवार्य रूप से इससे कोई फर्क नहीं पड़ता (POST और GET पर्याप्त हैं) और दाईं ओर उपयुक्त HTTP विधियों का उपयोग किया जाता है।

दाईं ओर सुरुचिपूर्ण, स्वच्छ और पेशेवर दिखता है। कल्पना कीजिए कि अब आपको एक कोड बनाए रखना होगा जो सुरुचिपूर्ण एपीआई का उपयोग कर रहा है और आपको यह खोजना होगा कि डिलीट कॉल कहाँ किया गया है। आप "एपीआई / इकाई" की खोज करेंगे और परिणामों के बीच आपको यह देखना होगा कि कौन सा व्यक्ति DELETE कर रहा है। या इससे भी बदतर, आपके पास एक जूनियर प्रोग्रामर है जो गलती से PUT को DELETE के साथ बदल देता है और जैसा URL है वैसा ही हुआ।

मेरी राय में URL में एक्शन क्रिया डालने से उस एक्शन के लिए उपयुक्त HTTP विधि का उपयोग करने पर लाभ होता है, भले ही वह कितना ही सुंदर क्यों न हो। यदि आप यह देखना चाहते हैं कि डिलीट कॉल कहां की गई है तो आपको बस "एपीआई / यूनिट / डिलीट" की खोज करनी होगी और आपको यह तुरंत मिल जाएगा।

संपूर्ण HTTP सरणी विधियों के बिना एक एपीआई का निर्माण करना बाद में उपभोग करना और बनाए रखना आसान बनाता है

Answer 4

सुरक्षित तरीके: संसाधन प्राप्त करें / संसाधन में कोई संशोधन न करें।
बेरोजगारी: कई बार अनुरोध किए जाने पर संसाधन की स्थिति में कोई परिवर्तन नहीं।
असुरक्षित तरीके: संसाधन में संसाधन अद्यतन करें / अद्यतन करें
गैर-बेरोजगार: यदि कई बार अनुरोध किया जाता है, तो संसाधन स्थिति में परिवर्तन करें

अपनी आवश्यकता के अनुसार:

1) सुरक्षित और सुस्पष्ट संचालन (फ़ॉच रिसोर्स) के उपयोग के लिए --------- GET METHOD
2) असुरक्षित और नॉन-इम्पोटेंट ऑपरेशन (इन्सर्ट संसाधन) के उपयोग के लिए --------- POST METHOD
3) असुरक्षित और बेकार ऑपरेशन (अपडेट संसाधन) के लिए उपयोग --------- PUT METHOD
3) असुरक्षित और बेरोजगार ऑपरेशन (डिलीट रिसोर्स) के उपयोग के लिए --------- DELETE METHOD