HTTP GET, PUT, DELETE, POST, HEAD का उपयोग करने का व्यावहारिक लाभ क्या है? अपने व्यवहार लाभ (सुरक्षा और idempotency) पर ध्यान केंद्रित क्यों नहीं करते, उनके नाम भूल जाते हैं, और हम किस व्यवहार के आधार पर जीईटी, पुट या POST का उपयोग करते हैं?हमें HTTP GET, PUT, POST से कुछ और क्यों चाहिए?
हमें केवल GET, PUT और POST (और HEAD, DELETE) का उपयोग क्यों नहीं करना चाहिए?
[REST] [1] दृष्टिकोण वेब संसाधन के लिए CRUD नियमों को लागू करने के लिए POST, GET, PUT और DELETE का उपयोग करता है। यह वेब पर अनुरोधों के लिए ऑब्जेक्ट्स का पर्दाफाश करने का एक सरल और साफ तरीका है। यह बिना किसी ओवरहेड के वेब सेवाएं है।
अर्थात् मतभेदों को स्पष्ट करने के लिए। प्रत्येक ऑपरेशन अलग है। बिंदु यह है कि अच्छे HTTP विधियां हैं जिनके स्पष्ट, स्पष्ट अर्थ हैं।
पोस्ट नई वस्तुओं को बनाता है। यूआरआई की कोई कुंजी नहीं है; यह एक संदेश निकाय स्वीकार करता है जो वस्तु को परिभाषित करता है। एसक्यूएल सम्मिलित करें। [संपादित कोई तकनीकी कारण पोस्ट कोई कुंजी है करने के लिए के लिए है, वहीं बाकी लोगों को दृढ़ता से सुझाव पोस्ट अलग अर्थ बनाने के रूप में करने के लिए के लिए, यह एक महत्वपूर्ण नहीं होना चाहिए कि।]
प्राप्त मौजूदा वस्तुओं प्राप्त करता है। यूआरआई एक कुंजी है, इस पर निर्भर करता है कि आप सिंगलटन प्राप्त कर रहे हैं या सूची प्राप्त करें। एसक्यूएल का चयन
PUT एक मौजूदा ऑब्जेक्ट को अद्यतन करता है। यूआरआई की एक कुंजी है; यह एक संदेश निकाय स्वीकार करता है जो किसी ऑब्जेक्ट को अपडेट करता है। एसक्यूएल अपडेट
DELETE किसी मौजूदा ऑब्जेक्ट को हटा देता है। यूआरआई की एक कुंजी है। एसक्यूएल हटाएं।
क्या आप पुट के बजाय POST के साथ एक रिकॉर्ड अपडेट कर सकते हैं? कुछ अस्पष्टता शुरू किए बिना नहीं। क्रियाओं के स्पष्ट प्रभाव होना चाहिए। इसके अलावा, पोस्ट यूआरआई की कोई कुंजी नहीं है, जहां PUT की कुंजी होनी चाहिए।
जब मैं पोस्ट करता हूं, तो मुझे 201 क्रेडिट की उम्मीद है। अगर मुझे यह नहीं मिलता है, तो कुछ गलत है। इसी तरह, जब मैं पुट करता हूं, तो मुझे 200 ओके की उम्मीद है। अगर मुझे यह नहीं मिलता है, तो कुछ गलत है।
मुझे लगता है कि आप कुछ अस्पष्टता पर जोर दे सकते हैं जहां पोस्ट या तो पोस्ट या पुट करता है। यूआरआई अलग होना है; संबंधित संदेश भी अलग हो सकता है। आम तौर पर, आरईएसटी लोग एसक्यूएल से अपना क्यू लेते हैं जहां आईएनएसईआरटी और अपडेट अलग-अलग क्रियाएं होती हैं।
आप यह मामला बना सकते हैं कि यदि रिकॉर्ड मौजूद नहीं है या रिकॉर्ड मौजूद है तो अद्यतन अद्यतन नहीं होना चाहिए। हालांकि, यह आसान है अगर अद्यतन का मतलब अद्यतन हो और अद्यतन करने में विफलता का अर्थ कुछ गलत है। आईएनएसईआरटी के लिए एक गुप्त गिरावट ऑपरेशन संदिग्ध बनाता है।
यदि आप एक विश्वसनीय इंटरफ़ेस नहीं बना रहे हैं, तो यह पुनर्प्राप्त करने और बनाने/अपडेट करने के लिए केवल GET और POST का उपयोग करना सामान्य है। जब कोई व्यक्ति किसी फॉर्म पर सबमिट करने पर क्लिक कर रहा है तो पोस्ट और PUT के बीच अंतर करने के लिए यूआरआई मतभेद या संदेश सामग्री अंतर होना आम बात है। हालांकि, यह बहुत साफ नहीं है क्योंकि आपके कोड को यह निर्धारित करना है कि क्या आप POST = create केस या POST = अद्यतन केस में हैं या नहीं।
हां, लेकिन यह मेरे प्रश्न का उत्तर नहीं देता है। मैं पूछ रहा था कि आप PUT का उपयोग करने से भी परेशान क्यों होंगे, जब प्राप्त करें, पोस्ट करें नौकरी ठीक करेगी? कौन व्यवहार करता है यदि व्यवहार समान है तो उनके नाम क्या हैं? – Gili
व्यवहार समान नहीं है। पुट पोस्ट के समान नहीं है। PUT अद्यतन के अनुरूप है, POST बनाने के अनुरूप है। अर्थशास्त्र पूरी तरह से अलग हैं। –
मुझे कोई तकनीकी कारण नहीं दिख रहा है कि आप POST का उपयोग करके रिकॉर्ड अपडेट नहीं कर सके। एक ऐसा सम्मेलन हो सकता है जो कहता है कि आपको एक या दूसरे का उपयोग करना चाहिए, लेकिन तकनीकी स्तर पर मुझे नहीं लगता कि इससे कोई फर्क पड़ता है। – Gili
हमें POST से अधिक क्यों चाहिए? यह डेटा को दोनों तरीकों से बहने की अनुमति देता है, तो क्यों आवश्यकता होगी? जवाब मूल रूप से आपके प्रश्न के समान ही है। विभिन्न तरीकों की मूल अपेक्षाओं को मानकीकृत करके अन्य प्रक्रियाएं बेहतर जान सकती हैं कि क्या करना है।
उदाहरण के लिए, कैशिंग प्रॉक्सी हस्तक्षेप करने से सही चीज़ करने का बेहतर मौका हो सकता है।
उदाहरण के लिए हेड के बारे में सोचें। यदि प्रॉक्सी सर्वर जानता है कि HEAD का अर्थ क्या है तो यह एक हेड अनुरोध के उचित उत्तर प्रदान करने के लिए पिछले जीईटी अनुरोध से परिणाम को संसाधित कर सकता है। और यह पता चलेगा कि पोस्ट, पुट और डिलीट कैश नहीं किया जाना चाहिए।
मुझे संदेह है कि HTTP POST प्रॉक्सी सर्वर को उस यूआरएल से जुड़े किसी भी कैश किए गए प्रविष्टियों को डंप करने का कारण बनता है (लेकिन मुझे यह HTTP विनिर्देशन में किसी भी तरह से चर्चा नहीं मिल सकती है)। यदि यह सत्य है, तो POST को PUT को प्रतिस्थापित नहीं करता है और हटा देता है? – Gili
विनिर्देश के अनुसार, जैसा कि मुझे याद है: प्राप्त करें - डेटा प्राप्त करें। पुट - डेटा भेजें, जो भविष्य में लाने योग्य होना चाहिए। पोस्ट - एक "प्रोग्राम" में डेटा भेजें और एक प्रतिक्रिया प्राप्त करें। शायद इन परिभाषाओं से मेल खाने के लिए एक कैश डिज़ाइन किया जाएगा। – Darron
सभी होस्टर्स पुट का समर्थन नहीं करते हैं, हटाएं।
मैं इस सवाल का, एक आदर्श दुनिया में हम सभी क्रियाओं लेकिन होगा .... पूछा:
अस्पष्टता जो बेहतर करने के लिए अनुमति देगा सीमित करने के लिए/हमारे सरल बाकी की आसान पुन: उपयोग apis।
आप केवल जीईटी और पोस्ट का उपयोग कर सकते हैं लेकिन फिर आप कुछ परिशुद्धता और स्पष्टता पर खो रहे हैं जो पुट और हटाएं। पोस्ट एक वाइल्डकार्ड ऑपरेशन है जिसका अर्थ कुछ भी हो सकता है। पुट और डिलीट का व्यवहार बहुत अच्छी तरह से परिभाषित किया गया है। यदि आप संसाधन प्रबंधन API के बारे में सोचते हैं तो प्राप्त करें, PUT और DELETE संभवतः आवश्यक कार्यक्षमता का 80% -90% कवर करें। यदि आप स्वयं को जीईटी और पोस्ट करने के लिए सीमित करते हैं तो आपके एपीआई का 40% -60% खराब निर्दिष्ट POST का उपयोग करके एक्सेस किया जाता है।
पहले के दिनों से वेब सर्वर युद्ध शायद इसका कारण बनता है।
HTTP 1.0 written in 1996, there were only GET, HEAD, and POST में। लेकिन जैसा कि आप Appendix D में देख सकते हैं, विक्रेताओं ने अपनी खुद की चीजें जोड़ना शुरू कर दिया। इसलिए, HTTP संगत रखने के लिए, उन्हें HTTP 1.1 in 1999 बनाने के लिए मजबूर होना पड़ा।
हालांकि, HTTP/1.0 पर्याप्त रूप से ध्यान में श्रेणीबद्ध प्रॉक्सी कैशिंग के प्रभाव, लगातार कनेक्शन, या आभासी मेजबान के लिए की जरूरत ले करता है। इसके अलावा, अधूरे से लागू अनुप्रयोगों के प्रसार खुद को "HTTP/1.0" दो आवेदनों संवाद स्थापित करने के लिए एक दूसरे से सच क्षमताओं का निर्धारण करने के लिए आदेश में उस प्रोटोकॉल संस्करण परिवर्तन जरूरी हो गया है।
यह विनिर्देश प्रोटोकॉल को "HTTP/1.1" के रूप में संदर्भित करता है। इस प्रोटोकॉल में इसकी विशेषताएं के विश्वसनीय कार्यान्वयन को सुनिश्चित करने के लिए क्रम में HTTP/1.0 की तुलना में अधिक कठोर आवश्यकताओं को शामिल किया गया है।
जीईटी और पोस्ट का उपयोग कर वेब एप्लिकेशन उपयोगकर्ताओं को अपने डेटा को बनाने, देखने, संशोधित करने और हटाने की अनुमति देते हैं, लेकिन मूल रूप से इन उद्देश्यों के लिए बनाए गए HTTP आदेशों के ऊपर एक परत पर ऐसा करते हैं। आरईएसटी के पीछे विचारों में से एक वेब के डिजाइन के मूल उद्देश्य पर वापसी है, जिससे प्रत्येक सीआरयूडी क्रिया के लिए विशिष्ट HTTP संचालन होते हैं।
इसके अलावा, HEAD कमांड का उपयोग उपयोगकर्ता संभावित (संभावित रूप से बड़े) फ़ाइल डाउनलोड के लिए उपयोगकर्ता अनुभव को बेहतर बनाने के लिए किया जा सकता है। आप यह जानने के लिए हेड को कॉल करते हैं कि प्रतिक्रिया कितनी बड़ी होगी और फिर सामग्री को वास्तव में पुनर्प्राप्त करने के लिए GET को कॉल करें।
एक उदाहरण उदाहरण के लिए निम्नलिखित link देखें। यह विकल्प http विधि का उपयोग करने का एक तरीका भी सुझाता है, जिस पर अभी तक चर्चा नहीं हुई है।
प्राप्त करें, पुट, हटाएं और पोस्ट एक युग से होल्डओवर हैं जब सोफोमोर्स ने सोचा था कि एक वेब पेज कुछ हद तक-टोटी सिद्धांतों में कम किया जा सकता है।
आजकल ज्यादातर वेब पृष्ठों समग्र संस्थाओं, जो इनमें से कुछ या आदिम कार्यों के सभी शामिल हैं।उदाहरण के लिए, एक पृष्ठ में ग्राहक जानकारी देखने या अपडेट करने के लिए फॉर्म हो सकते हैं, जो शायद कई तालिकाओं को फैलाता है।
मैं आमतौर पर PHP में $ _REQUEST [] का उपयोग करता हूं, वास्तव में यह नहीं बताता कि जानकारी कैसे पहुंची। मैं दक्षता के आधार पर जीईटी या पुट विधियों का उपयोग करना चुनूंगा, अंतर्निहित (एकाधिक) प्रतिमान नहीं।
कोई स्वयं को समझाना चाहता है? मैं उत्सुक हूँ। – dar7yl
क्या आप नीचे मतदान के बारे में पूछ रहे हैं? –
हां, (आप इस हैंडशेकिंग का जवाब दे सकते थे) मेरा मुद्दा यह है कि अधिकांश वेब पेज प्रतिमान आदर्श के अनुरूप नहीं होते हैं, और प्राप्त करें और मतभेदों को भी लागू नहीं किया जा सकता है, इसलिए अंतर्निहित अवधारणा त्रुटिपूर्ण है। – dar7yl
POSTsafety or idempotency की कोई गारंटी नहीं है। PUT और DELETE -both PUT और DELETE बेवकूफ हैं (यानी, 1 + एन समान अनुरोधों के पास केवल 1 अनुरोध के समान परिणाम होता है)।
किसी दिए गए यूआरआई में संसाधन की स्थिति के लिए उपयोग किया जाता है। जब आप एक विशेष यूआरआई, पर एक संसाधन के लिए एक पोस्ट अनुरोध भेजने के संसाधनसामग्री द्वारा जगह नहीं होना चाहिए। सबसे अधिक, यह संलग्न होना चाहिए। यही कारण है कि पोस्ट स्थगित नहीं है- POSTS को जोड़ने के मामले में, प्रत्येक अनुरोध संसाधन में जोड़ देगा (उदाहरण के लिए, प्रत्येक बार चर्चा मंच पर नया संदेश पोस्ट करें)।
DELETE यह सुनिश्चित करने के लिए उपयोग किया जाता है कि किसी दिए गए यूआरआई पर संसाधन सर्वर से हटा दिया जाता है। POST को को हटाने का अनुरोध सबमिट करने के मामले को छोड़कर सामान्य रूप से उपयोग करने के लिए उपयोग नहीं किया जाना चाहिए। फिर, उस मामले में जो संसाधन आप पोस्ट करेंगे, उस यूआरआई को उस संसाधन के लिए यूआरआई नहीं होना चाहिए जिसे आप हटाना चाहते हैं। कोई भी संसाधन जिसके लिए आप पोस्ट करते हैं वह एक संसाधन है जो पोस्ट किए गए डेटा को स्वयं संलग्न करने, संग्रह में जोड़ने या किसी अन्य तरीके से प्रक्रिया करने के लिए स्वीकार करता है।
HEAD का उपयोग तब किया जाता है जब आप सभी को एक जीईटी अनुरोध के शीर्षलेख हैं और आप वास्तविक सामग्री पर बैंडविड्थ बर्बाद नहीं करना चाहते हैं। यह अच्छा है।
कोई भी जिस तरह का उत्तर ढूंढ रहा था, उसे पोस्ट नहीं किया गया, इसलिए मैं खुद को अंक सारांशित करने का प्रयास करूंगा।
"रीस्टफुल वेब सर्विसेज" अध्याय 8 खंड "ओवरलोडिंग पोस्ट" पढ़ता है: "यदि आप पूरी तरह से पुट के बिना करना चाहते हैं और पूरी तरह से हटा देना चाहते हैं, तो यह पूरी तरह से अधिभारित पोस्ट के माध्यम से जीईटी, और अन्य सभी परिचालनों के माध्यम से संसाधनों पर सुरक्षित संचालन का पर्दाफाश करने के लिए पूरी तरह से सही है। ऐसा करने से मेरा संसाधन-ओरिएंटेड आर्किटेक्चर का उल्लंघन होता है, लेकिन यह आरईएसटी के कम प्रतिबंधक नियमों के अनुरूप है। "
संक्षेप में, POST के पक्ष में PUT/DELETE को प्रतिस्थापित करने से एपीआई को पढ़ने में कठिनाई होती है और कॉल/हटाएं कॉल अब निष्क्रिय नहीं हैं।
वेबएडीवी जैसे http एक्सटेंशन हैं जिन्हें अतिरिक्त कार्यात्मक रूप से आवश्यकता होती है।
एक शब्द में:
idempotency
कुछ और शब्दों में:
प्राप्त = सुरक्षित + idempotent
PUT = idempotent
DELETE = idempotent
पोस्ट = न सुरक्षित या idempotent
'idempotent सिर्फ आप इसे बार बार कर सकते हैं और यह हमेशा बिल्कुल वही बात करेंगे मतलब है।
आप जितनी बार चाहें पुट (अपडेट) या डिलीट अनुरोध को फिर से जारी कर सकते हैं और यह हर बार एक ही प्रभाव होगा, हालांकि वांछित प्रभाव संसाधन को संशोधित करेगा, इसलिए इसे 'सुरक्षित' नहीं माना जाता है।
एक POST अनुरोध प्रत्येक अनुरोध के साथ एक नया संसाधन बनाना चाहिए, जिसका अर्थ है कि प्रभाव हर बार अलग होगा। इसलिए पोस्ट सुरक्षित या बेवकूफ नहीं माना जाता है।
जीईटी और हेड जैसे तरीके केवल पढ़े गए ऑपरेशन हैं और इसलिए उन्हें 'सुरक्षित' और बेवकूफ माना जाता है।
यह वास्तव में एक बहुत ही महत्वपूर्ण अवधारणा है क्योंकि यह HTTP लेनदेन की व्याख्या करने के लिए एक मानक/सुसंगत तरीका प्रदान करता है; यह सुरक्षा संदर्भ में विशेष रूप से उपयोगी है।
तो मेरा बिंदु तब बन जाता है, क्यों विधि नाम के बजाय विभिन्न श्रेणियों पर ध्यान केंद्रित नहीं करते? 1) जब आप सुरक्षित चाहते हैं + idempotent केवल HEET को समाप्त करने, GET का उपयोग करें। 2) जब आप idempotent केवल PUT का उपयोग करते हैं, DELETE को समाप्त करते हैं। 3) जब आप न केवल पोस्ट का उपयोग करना चाहते हैं। – Gili
HEAD वास्तव में यह निर्धारित करने के लिए उपयोगी है कि किसी दिए गए सर्वर की घड़ी को सेट किया गया है (1 सेकंड के भीतर सटीक या नेटवर्क राउंड-ट्रिप टाइम, जो भी अधिक हो)। यह भी Slashdot से फ़्यूचरामा उद्धरण प्राप्त करने के लिए बहुत अच्छा है:
~$ curl -I slashdot.org HTTP/1.1 200 OK Date: Wed, 29 Oct 2008 05:35:13 GMT Server: Apache/1.3.41 (Unix) mod_perl/1.31-rc4 SLASH_LOG_DATA: shtml X-Powered-By: Slash 2.005001227 X-Fry: That's a chick show. I prefer programs of the genre: World's Blankiest Blank. Cache-Control: private Pragma: private Connection: close Content-Type: text/html; charset=iso-8859-1
cURL के लिए, -I एक HEAD अनुरोध प्रदर्शन करने के लिए विकल्प नहीं है। किसी दिए गए सर्वर वर्तमान दिनांक और समय के लिए, बस
curl -I $server | grep ^Date
कर आप केवल प्राप्त और पोस्ट का उपयोग करने का सुझाव दे रहे हैं? मैं इसे बाहर नहीं कर सका। – Till
इसे इंगित करने के लिए धन्यवाद, मैंने प्रश्न स्पष्ट किया है। – Gili
गिली, नीचे आप भी PUT बाहर फेंकना चाहते हैं। मुझे लगता है कि आपको स्क्रैच से सवाल फिर से लिखना होगा। ऐसा लगता है कि वेब जीईटी और पोस्ट के साथ मिलता है, इसलिए शायद वे पर्याप्त हैं। – pbreitenbach