HTTP प्रोटोकॉल में GET और POST जैसे तरीकों की क्या आवश्यकता है?


17

क्या हम सिर्फ एक अनुरोध निकाय और एक प्रतिक्रिया निकाय का उपयोग करके HTTP प्रोटोकॉल को लागू नहीं कर सकते हैं?

उदाहरण के लिए, URL में अनुरोध शामिल होगा, जिसे सर्वर फ़ंक्शन पर प्रोग्रामिंग भाषा के आधार पर एक फ़ंक्शन में मैप किया जाएगा, एक सर्वलेट कहता है और जवाब में HTML और जावास्क्रिप्ट प्रतिक्रिया भर में भेजा जाएगा।

HTTP प्रोटोकॉल में विधियों की धारणा क्यों है?

जवाब से, मुझे कुछ समझ में आता है कि तरीकों की अवधारणा क्यों है..यह एक अन्य संबंधित प्रश्न की ओर जाता है:

उदाहरण के लिए gmail कंपोज़ लिंक में, PUT / POST अनुरोध और डेटा भेजा जाएगा। ब्राउज़र को कैसे पता चलता है कि किस विधि का उपयोग करना है? क्या सर्वर द्वारा भेजे गए gmail पेज में gmail कंपोज रिक्वेस्ट कॉल करते समय उपयोग करने की विधि का नाम शामिल है? जब हम www.gmail.com को कॉल करते हैं, तो उसे GET विधि का उपयोग करना चाहिए, ब्राउज़र को यह कैसे पता चलेगा कि इस विधि का उपयोग करना है?

पुनश्च : मेरे पास उत्तरों पर टिप्पणी करने के लिए पर्याप्त क्रेडिट नहीं है, इसलिए मैं इस प्रश्न के पीछे के इरादे से संबंधित लोगों द्वारा उठाए गए कई सवालों पर टिप्पणी करने में सक्षम नहीं हूं।

जैसा कि कुछ उत्तर बताते हैं, हम DELETE पद्धति पर नए उपयोगकर्ता बना सकते हैं, फिर यह http प्रोटोकॉल में विधियों की धारणा के पीछे की मंशा पर सवाल उठाता है, क्योंकि दिन के अंत में, यह पूरी तरह से सर्वरों पर निर्भर करता है कि वे किस फ़ंक्शन के लिए URL मैप करना चाहते हैं । क्‍लाइंट को सर्वरों को यह बताना चाहिए कि URL के लिए कौन से तरीके उपयोग करने चाहिए।


हां और ना। आपका प्रश्न अपने आप से टकराता है जैसा कि आप कहते हैं कि आप जानना चाहते हैं कि HTTP का उपयोग किए बिना HTTP अनुरोध कैसे करें, लेकिन मुझे लगता है कि मुझे वह मिलता है जो आप करने की कोशिश कर रहे हैं। अर्थात्, एक ब्राउज़र का उपयोग किए बिना GET और POST डेटा लेकिन यह प्रोग्रामेटिक रूप से कर रहा है। क्या वो सही है?
रोब

4
मुझे आश्चर्य है, क्या आप पूछ रहे हैं कि क्या HTTP को तरीकों के बिना परिभाषित किया जा सकता है, अर्थात उनके लिए ऐतिहासिक तर्क; या यदि प्रोटोकॉल के रूप में यह वर्तमान में उनके बिना इस्तेमाल किया जा सकता है, यानी छोड़ने के तरीकों मौजूदा विनिर्देश के भीतर होगा?
ilkachachu

@ilkkachu: क्लाइंट को सर्वर को यह बताने की आवश्यकता क्यों है कि किसी चीज़ को कैसे निष्पादित किया जाए। क्लाइंट केवल URL के लिए और URL का उपयोग करने के लिए अनुरोध करेगा, उदाहरण के लिए सर्वर इसे फ़ंक्शन फ़ंक्शन सर्वलेट में मैप कर सकता है और प्रतिक्रिया प्रदान कर सकता है। क्लाइंट को कभी भी कुछ प्रदान करने की आवश्यकता क्यों होनी चाहिए?
user104656

1
@ user104656, यदि यह मेरे प्रश्न का उत्तर है, तो मुझे अभी भी यकीन नहीं है कि आप मूल डिजाइन या वर्तमान स्थिति से मतलब रखते हैं। (मैंने यह नहीं कहा कि इसकी आवश्यकता है या इसकी आवश्यकता नहीं है।)
kkkachu

@Mars और अन्य: जीमेल कम्पोज़ लिंक में उदाहरण के लिए, PUT / POST अनुरोध और डेटा भेजा जाएगा। ब्राउज़र को कैसे पता चलता है कि किस विधि का उपयोग करना है? क्या सर्वर द्वारा भेजे गए gmail पेज में gmail कंपोज रिक्वेस्ट कॉल करते समय उपयोग करने की विधि का नाम शामिल है? जब हम www.gmail.com को कॉल करते हैं, तो उसे GET विधि का उपयोग करना चाहिए, ब्राउज़र को कैसे पता चलेगा कि इस विधि का उपयोग करना है?
बायोलॉजिक

जवाबों:


33

कृपया ध्यान दें कि यह उत्तर पहली बार लिखे जाने के बाद से प्रश्न बदल गया है / स्पष्ट कर दिया गया है। प्रश्न के नवीनतम पुनरावृत्ति के लिए एक और प्रतिक्रिया दूसरी क्षैतिज नियम के बाद है

HTTP प्रोटोकॉल में GET और POST जैसे तरीकों की क्या आवश्यकता है?

वे हेडर फॉर्मेट्स, हेडर और बॉडीज को अलग करने जैसे नियमों के साथ HTTP प्रोटोकॉल का आधार बनाते हैं

क्या हम सिर्फ एक अनुरोध निकाय और एक प्रतिक्रिया निकाय का उपयोग करके HTTP प्रोटोकॉल को लागू नहीं कर सकते हैं?

नहीं, क्योंकि तब आपने जो भी बनाया था वह HTTP प्रोटोकॉल नहीं होगा

उदाहरण के लिए, URL में अनुरोध शामिल होगा, जिसे सर्वर फ़ंक्शन पर प्रोग्रामिंग भाषा के आधार पर एक फ़ंक्शन में मैप किया जाएगा, एक सर्वलेट कहता है और जवाब में HTML और जावास्क्रिप्ट प्रतिक्रिया भर में भेजा जाएगा।

बधाई हो, आपने अभी नया प्रोटोकॉल ईजाद किया है! अब, यदि आप ड्राइव करने और इसे बनाए रखने, इसे विकसित करने आदि के लिए एक मानक निकाय स्थापित करना चाहते हैं, तो यह एक दिन HTTP से आगे निकल सकता है

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

इंटरनेट पर वापस, यदि आप एक वेब सर्वर के लिए एक सॉकेट खोलते हैं जो HTTP शिकायत है और निम्नलिखित भेजें:

EHLO
AUTH LOGIN

(एक SMTP ईमेल ट्रांसमिशन की शुरुआत) तो आप समझदार जवाब नहीं मिलेगा। आप सबसे सही SMTP अनुरूप ग्राहक तैयार कर सकते हैं, लेकिन आपका वेबसर्वर इससे बात नहीं करेगा क्योंकि यह बातचीत साझा प्रोटोकॉल के बारे में है - कोई साझा प्रोटोकॉल, कोई खुशी नहीं।

यही कारण है कि आप HTTP प्रोटोकॉल को लागू किए बिना HTTP प्रोटोकॉल को लागू नहीं कर सकते हैं; यदि आप जो लिखते हैं वह प्रोटोकॉल के अनुरूप नहीं है, तो यह केवल प्रोटोकॉल नहीं है - यह कुछ और है, और यह प्रोटोकॉल में निर्दिष्ट के रूप में काम नहीं करेगा।

अगर हम एक पल के लिए आपके उदाहरण के साथ चलते हैं; जहां क्लाइंट कनेक्ट होता है और बस कुछ ऐसा बताता है जो URL की तरह दिखता है .. और सर्वर इसे समझता है और बस कुछ ऐसा भेजता है जो HTML / JS (एक वेबपेज) जैसा दिखता है, तो यकीन है, यह काम कर सकता है। हालांकि आपने क्या बचाया? GET नहीं कहने पर युगल बाइट? कम उन pesky हेडर खाई पर अधिक .. सर्वर कुछ भी बचाया - लेकिन क्या हुआ अगर तुम बाहर काम नहीं कर सकते हैं क्या यह तुम्हें भेजा? क्या होगा यदि आपने जेपीईजी में समाप्त होने वाले URL के लिए पूछा, और इसने आपको कुछ बाइट्स भेजे जो एक तस्वीर बनाते हैं, लेकिन यह पीएनजी में है? उस पर एक अपूर्ण पीएनजी। यदि केवल हम एक ऐसा हेडर ने कहा कि यह कितने बाइट्स रहा था जा रहाभेजने के लिए, तब हमें पता चलेगा कि हमें प्राप्त बाइट्स की संख्या वास्तव में पूरी फाइल थी या नहीं। क्या होगा अगर सर्वर ने कुछ बैंडविड्थ को बचाने के लिए प्रतिक्रिया को gzipped किया लेकिन आपको नहीं बताया? आप कुछ काफी कंप्यूटिंग शक्ति खर्च करने जा रहे हैं जो इसे भेजा है।

दिन के अंत में, हमें मेटैनफॉर्मेशन की आवश्यकता है - जानकारी के बारे में जानकारी; हमें हेडर की आवश्यकता है; हमें नाम, एक्सटेंशन, बनाई गई तिथियों के लिए फ़ाइलों की आवश्यकता है। हमें लोगों को जन्मदिन, कृपया और थैंक्यू आदि कहने की ज़रूरत है - दुनिया संदर्भ के बारे में जानकारी के बिट्स और बिट्स से भरी है, इसलिए हमें हर समय खरोंच से बैठकर काम करने की ज़रूरत नहीं है। यह भंडारण स्थान का एक सा खर्च करता है, लेकिन यह आसानी से इसके लायक है


क्या विभिन्न HTTP विधियों को लागू करना वास्तव में आवश्यक है?

यकीनन, किसी को पूरे निर्दिष्ट प्रोटोकॉल को लागू करने की आवश्यकता नहीं है, और यह आमतौर पर किसी भी चीज के लिए सच है। मैं अंग्रेजी भाषा में हर शब्द नहीं जानता; मेरे चीनी पड़ोसी एक सॉफ्टवेयर डेवलपर भी हैं, लेकिन एक अलग उद्योग में हैं और वह नहीं जानते हैं कि मेरे उद्योग में इस्तेमाल होने वाले कुछ शब्दों के लिए भी चीनी अकेले ही अंग्रेजी को जाने देते हैं। हालांकि अच्छी बात यह है कि हम दोनों HTTP के कार्यान्वयन पर एक दस्तावेज़ ले सकते हैं, वह सर्वर लिख सकता है और मैं क्लाइंट को विभिन्न आर्किटेक्चर पर विभिन्न प्रोग्रामिंग भाषाओं में लिख सकता हूं, और वे अभी भी काम करते हैं क्योंकि वे प्रोटोकॉल का पालन करते हैं

यह अच्छी तरह से हो सकता है कि आपका कोई भी उपयोगकर्ता कभी भी GET अनुरोध के अलावा कुछ भी जारी नहीं करेगा, लगातार कनेक्शन का उपयोग नहीं करेगा, JSON के अलावा किसी अन्य वस्तु को शरीर के रूप में भेजें, या पाठ / सादे के अलावा कुछ भी स्वीकार करने की आवश्यकता है ताकि आप कर सकें वेब सर्वर के लिए एक बहुत ही सीमित आलेख लिखें जो केवल क्लाइंट ब्राउज़र की बहुत सीमित मांगों को पूरा करता है। लेकिन आप केवल मनमाने ढंग से उन बुनियादी नियमों से दूर होने का फैसला नहीं कर सकते जो "कुछ पाठ एक सॉकेट के नीचे से गुजरते हैं" जो HTTP है; आप मूल धारणा को नहीं खो सकते हैं कि अनुरोध एक स्ट्रिंग की तरह होगा:

VERB URL VERSION
header: value

maybe_body

और प्रतिक्रिया में एक संस्करण, और स्थिति कोड और शायद हेडर होंगे। यदि आप इनमें से किसी को भी बदलते हैं - यह HTTP नहीं है - यह कुछ और है, और केवल कुछ के साथ काम करेगा जिसे इसे समझने के लिए डिज़ाइन किया गया है। HTTP यह वही है जो इन परिभाषाओं द्वारा है, इसलिए यदि आप इसे लागू करना चाहते हैं, तो आपको परिभाषाओं का पालन करना होगा


अपडेट करें

आपका प्रश्न थोड़ा सा विकसित हो गया है, यहाँ कुछ प्रतिक्रिया है जो आप पूछते हैं:

HTTP प्रोटोकॉल में विधियों की धारणा क्यों है?

ऐतिहासिक रूप से आपको यह सराहना करने की आवश्यकता है कि चीजें उनके डिजाइन और कार्यान्वयन में बहुत अधिक अनम्य थीं, यहां तक ​​कि स्क्रिप्टिंग भी मौजूद नहीं थी और यहां तक ​​कि यह धारणा भी थी कि पृष्ठ गतिशील हो सकते हैं, स्मृति में मक्खी पर उत्पन्न होते हैं और इसके बजाय सॉकेट को नीचे धकेल दिया जाता है ग्राहक द्वारा अनुरोधित डिस्क पर एक स्थिर फ़ाइल होने और सॉकेट को नीचे पढ़ने और धकेलने के लिए मौजूद नहीं था। जैसे कि बहुत प्रारंभिक वेब स्थिर पृष्ठों की धारणा के आसपास केंद्रित था जिसमें अन्य पृष्ठों के लिंक शामिल थे, सभी पृष्ठ डिस्क और नेविगेशन पर मौजूद थे जो टर्मिनल द्वारा अधिकतर URL पर पृष्ठों के लिए GET अनुरोध कर रहे थे, सर्वर मैप करने में सक्षम होगा url को डिस्क पर फ़ाइल में भेजें और भेजें। यह भी धारणा थी कि दस्तावेजों के वेब जो एक-दूसरे से और कहीं से जुड़े हुए हैं, एक विकसित होना चाहिए,

यह तरीकों के लिए कुछ ऐतिहासिक संदर्भ देता है- एक बार जब URL अनम्य बिट था, और सरलीकृत रूप से डिस्क पर पृष्ठों के लिए संदर्भित किया जाता था, इसलिए यह विधि उपयोगी थी क्योंकि यह क्लाइंट को यह वर्णन करने की अनुमति देता था कि फ़ाइल और सर्वर के लिए उसका क्या इरादा था विधि को कुछ अलग तरीके से संसाधित करें। वास्तव में एक हाइपरटेक्स्ट की मूल दृष्टि में स्विचिंग या मैपिंग के लिए यूआरएल के आभासी होने या इस्तेमाल होने की धारणा नहीं थी (और यह वास्तव में केवल पाठ था) वेब

मैं इस उत्तर के लिए तारीखों के साथ ऐतिहासिक रिकॉर्ड का दस्तावेजीकरण होने का इरादा नहीं कर रहा हूं और ठीक उसी समय के संदर्भों का हवाला दिया जब चीजें बदलने लगीं - इसके लिए आप शायद विकिपीडिया पढ़ सकते हैं - लेकिन यह कहना पर्याप्त है कि उस समय के लिए इच्छा वेब अधिक एकत्रित गति के लिए और सर्वर-क्लाइंट कनेक्शन के प्रत्येक छोर पर हमारे द्वारा विस्तारित किए जा रहे समृद्ध मल्टीमीडिया अनुभव बनाने के अवसर प्रदान करता है। ब्राउज़रों ने सामग्री को प्रारूपित करने के लिए टैग के एक विशाल प्रसार का समर्थन किया, प्रत्येक को मीडिया की समृद्धि सुविधाओं को लागू करने के लिए रेसिंग करना चाहिए और चीजों को बनाने के नए तरीके सूंघने लगते हैं।

स्क्रिप्टिंग क्लाइंट एंड और प्लगइन्स और ब्राउज़र एक्सटेंशन पर पहुंची, जिसका उद्देश्य ब्राउज़र को हर चीज की एक अत्यंत सक्षम बिजलीघर में बनाना था। एल्गोरिदम या डेटाबेस डेटा पर आधारित सामग्री के सर्वर एंड एक्टिव जनरेशन में बड़ा धक्का था और यह इस हद तक विकसित होता रहता है कि डिस्क पर शायद कुछ ही फाइलें होती हैं - निश्चित रूप से, हम चित्र या स्क्रिप्ट फ़ाइल को फ़ाइल के रूप में रखते हैं वेब सर्वर और ब्राउज़र को प्राप्त करें, लेकिन ब्राउज़र द्वारा दिखाए जाने वाले चित्रों को तेजी से बढ़ाता है और जो स्क्रिप्ट चलाता है वह ऐसी फाइलें नहीं हैं जिन्हें आप अपनी फ़ाइल एक्सप्लोरर में खोल सकते हैं, वे सामग्री उत्पन्न करते हैं जो मांग पर किए गए कुछ संकलन प्रक्रिया का आउटपुट है। , SVG जो वर्णन करता है कि पिक्सल के एक बिटमैप सरणी के बजाय पिक्सेल कैसे खींचना है, या जावास्क्रिप्ट जो टाइपस्क्रिप्ट के लिए उच्च स्तर की स्क्रिप्ट से उत्सर्जित किया गया था

आधुनिक बहु मेगाबाइट पृष्ठों को बनाने में शायद इसका एक अंश डिस्क पर निश्चित सामग्री है; डेटाबेस डेटा को HTML में स्वरूपित और आकार दिया जाता है जिसे ब्राउज़र उपभोग करेगा और यह सर्वर द्वारा कई अलग-अलग प्रोग्रामिंग रूटीनों के जवाब में किया जाता है जो यूआरएल द्वारा किसी तरह से संदर्भित होते हैं।

मैंने टिप्पणी में उल्लेख किया है कि यह पूर्ण चक्र की तरह है। जब कंप्यूटर पर सैकड़ों हजारों और भरे हुए कमरों की लागत होती है, तो कई उपयोगकर्ताओं को सैकड़ों सुपर डंबल टर्मिनलों के माध्यम से एक सुपर शक्तिशाली केंद्रीय मेनफ्रेम का उपयोग करने की अनुमति देना आम था - एक कुंजी बोर्ड और माउस, एक हरे रंग की स्क्रीन, कुछ पाठ भेजें, कुछ प्राप्त करें पाठ बाहर। समय के साथ-साथ कंप्यूटिंग शक्ति में वृद्धि हुई और कीमतें कम हुईं, लोगों ने डेस्क कंप्यूटर के साथ शुरुआती मेनफ्रेम की तुलना में अधिक शक्तिशाली और स्थानीय रूप से शक्तिशाली ऐप चलाने की क्षमता समाप्त करना शुरू कर दिया, इसलिए मेनफ्रेम मॉडल पुराना हो गया। हालांकि यह कभी दूर नहीं हुआ, क्योंकि चीजें सिर्फ दूसरे तरीके को स्थानांतरित करने के लिए विकसित हुईं और कुछ हद तक एक केंद्रीय सर्वर में वापस आ गईं, जो अधिकांश उपयोगी ऐप कार्यक्षमता और सौ क्लाइंट कंप्यूटर प्रदान करते हैं जो स्क्रीन पर ड्रा को छोड़कर बहुत कम करते हैं, और सर्वर से / के लिए डेटा जमा करें और प्राप्त करें। वह अंतरिम अवधि जहां आपका कंप्यूटर एक ही समय में वर्ड और आउटलुक की अपनी कॉपी को चलाने के लिए काफी स्मार्ट था, फिर से ऑनलाइन ऑफिस जाने का रास्ता दिया गया है, जहां आपका ब्राउज़र स्क्रीन पर चित्र बनाने और दस्तावेज़ / ईमेल को संपादित करने के लिए एक उपकरण है ' सर्वर पर रहने वाली चीज़ के रूप में फिर से लिखना, अन्य उपयोगकर्ताओं के साथ वहाँ भेजा, साझा किया गया है और इस धारणा के रूप में साझा किया जाता है कि ब्राउज़र सिर्फ एक शेल है जो इस चीज़ के किसी एक समय पर एक आंशिक दृश्य प्रदान करता है जो कहीं और रहता है

जवाब से, मुझे कुछ समझ में आता है कि तरीकों की अवधारणा क्यों है..यह एक अन्य संबंधित प्रश्न की ओर जाता है:

उदाहरण के लिए gmail कंपोज़ लिंक में, PUT / POST अनुरोध और डेटा भेजा जाएगा। ब्राउज़र को कैसे पता चलता है कि किस विधि का उपयोग करना है?

यह जीईटी का उपयोग डिफ़ॉल्ट रूप से, कन्वेंशन / कल्पना के द्वारा करता है, क्योंकि जब आप एक यूआरएल टाइप करते हैं और रिटर्न को दबाते हैं तो यह क्या घटता है

क्या सर्वर द्वारा भेजे गए gmail पेज में gmail कंपोज रिक्वेस्ट कॉल करते समय उपयोग करने की विधि का नाम शामिल है?

यह उन प्रमुख चीजों में से एक है जिन्हें मैं उपरोक्त टिप्पणियों में समझाता हूं। आधुनिक वेब में यह पृष्ठों के बारे में भी नहीं है। एक बार जब पेज डिस्क पर फाइल होते हैं, तो वह ब्राउज़र जीईटी हो जाता है। फिर वे ऐसे पृष्ठ बन गए जो मुख्य रूप से डेटा को टेम्पलेट में स्लॉट करके गतिशील रूप से उत्पन्न किए गए थे। लेकिन इसमें अभी भी "सर्वर से एक नया पृष्ठ अनुरोध, एक पृष्ठ, शो पेज" प्रक्रिया शामिल है। पृष्ठ अदला-बदली वास्तव में धीमी हो गई; आपने उन्हें लोड नहीं देखा और उनका आकार बदल दिया और उनके लेआउट को झटका दिया, ताकि वह चिकना हो जाए, लेकिन यह अभी भी ब्राउज़र को एक पेज या किसी पेज के दूसरे हिस्से को बदल रहा था

चीजों को करने का आधुनिक तरीका एक पृष्ठ के आवेदन के साथ है; ब्राउज़र में स्मृति में एक दस्तावेज़ होता है जो एक निश्चित तरीके से प्रदर्शित होता है, स्क्रिप्टिंग को thebservr पर कॉल करता है और जानकारी के कुछ डला जाता है, और दस्तावेज़ में हेरफेर करता है ताकि पृष्ठ का हिस्सा नई जानकारी दिखाने के लिए नेत्रहीन रूप से बदल जाए- पूरी चीजें बिना इसके ब्राउज़र कभी एक और नया पृष्ठ लोड कर रहा है; यह सिर्फ एक यूआई बन जाता है, जहाँ इसके कुछ हिस्से एक विशिष्ट क्लाइंट ऐप जैसे शब्द या आउटलुक की तरह ही अपडेट होते हैं। नए तत्व अन्य तत्वों के शीर्ष पर दिखाई देते हैं और डायलॉग विंडो आदि के आसपास खींचे जा सकते हैं। यह सब ब्राउज़र स्क्रिप्टिंग इंजन है जो डेवलपर जो भी http विधि चाहता है उसका उपयोग करके अनुरोध भेज रहा है, डेटा वापस प्राप्त कर रहा है और उस दस्तावेज़ पर प्रहार कर रहा है जो ब्राउज़र ड्राइंग कर रहा है। आप कल्पना कर सकते हैं कि आधुनिक ब्राउज़र एक शानदार उपकरण है जो संपूर्ण ऑपरेटिंग सिस्टम या वर्चुअल कंप्यूटर जैसा कुछ है; एक प्रोग्राम करने योग्य डिवाइस जिसमें स्क्रीन पर चीजों को खींचने, ध्वनि बजाने, उपयोगकर्ता इनपुट को कैप्चर करने और इसे प्रसंस्करण के लिए भेजने का काफी मानकीकृत तरीका है। आपको बस यह करना है कि अपने यूआई को ड्रा करें यह कुछ html / सीएसएस के साथ प्रदान करता है जो एक UI बनाता है फिर ब्राउज़र को क्या बदल रहा है इसे बनाने के लिए HTML को लगातार ट्वीक करें। बिल्ली, लोगों को पता बार परिवर्तन देखने के लिए उपयोग किया जाता है / इसे इरादे की दिशा के रूप में उपयोग किया जाता है कि एक एकल पृष्ठ ऐप, प्रोग्राम को व्यावहारिक रूप से बदल देगा भले ही कोई नेविगेशन (पूरे नए पृष्ठों का अनुरोध) नहीं किया जा रहा है आपको बस यह करना है कि अपने यूआई को ड्रा करें यह कुछ html / सीएसएस के साथ प्रदान करता है जो एक UI बनाता है फिर ब्राउज़र को क्या बदल रहा है इसे बनाने के लिए HTML को लगातार ट्वीक करें। बिल्ली, लोगों को पता बार परिवर्तन देखने के लिए उपयोग किया जाता है / इसे इरादे की दिशा के रूप में उपयोग किया जाता है कि एक एकल पृष्ठ ऐप, प्रोग्राम को व्यावहारिक रूप से बदल देगा भले ही कोई नेविगेशन (पूरे नए पृष्ठों का अनुरोध) नहीं किया जा रहा है आपको बस यह करना है कि अपने यूआई को ड्रा करें यह कुछ html / सीएसएस के साथ प्रदान करता है जो एक UI बनाता है फिर ब्राउज़र को क्या बदल रहा है इसे बनाने के लिए HTML को लगातार ट्वीक करें। बिल्ली, लोगों को पता बार परिवर्तन देखने के लिए उपयोग किया जाता है / इसे इरादे की दिशा के रूप में उपयोग किया जाता है कि एक एकल पृष्ठ ऐप, प्रोग्राम को व्यावहारिक रूप से बदल देगा भले ही कोई नेविगेशन (पूरे नए पृष्ठों का अनुरोध) नहीं किया जा रहा है

जब हम www.gmail.com को कॉल करते हैं, तो उसे GET विधि का उपयोग करना चाहिए, ब्राउज़र को यह कैसे पता चलेगा कि इस विधि का उपयोग करना है?

सच। क्योंकि यह निर्दिष्ट है। पहला अनुरोध यह है कि यह ऐतिहासिक रूप से हमेशा से रहा है- एक यूआई आकर्षित करने के लिए कुछ प्रारंभिक HTML प्राप्त करें, फिर या तो इसे हमेशा के लिए प्रहार और हेरफेर करें, या अन्य स्क्रिप्ट के साथ एक और पेज प्राप्त करें जो कि चुटकुले और हेरफेर करता है और एक उत्तरदायी प्रतिक्रियाशील UI बनाता है

जैसा कि कुछ उत्तर बताते हैं, हम DELETE पद्धति पर नए उपयोगकर्ता बना सकते हैं, फिर यह http प्रोटोकॉल में विधियों की धारणा के पीछे की मंशा पर सवाल उठाता है, क्योंकि दिन के अंत में, यह पूरी तरह से सर्वरों पर निर्भर करता है कि वे किस फ़ंक्शन के लिए URL मैप करना चाहते हैं । क्‍लाइंट को सर्वरों को यह बताना चाहिए कि URL के लिए कौन से तरीके उपयोग करने चाहिए।

इतिहास। विरासत। हम कल के सभी http तरीकों को सैद्धांतिक रूप से टॉस कर सकते हैं- हम एक प्रोग्रामिंग परिष्कार स्तर पर हैं, जहां विधियाँ अप्रचलित हैं क्योंकि URL इस हद तक प्रक्रियाशील हैं कि वे स्विचिंग तंत्र हो सकते हैं जो उस सर्वर को इंगित करता है जिसे आप डेटा को सहेजना चाहते हैं बॉडी एक ड्राफ्ट ईमेल के रूप में, या ड्राफ्ट डिलीट करें - सर्वर पर / ईमेल / ड्राफ्ट / सेव / 1234 फाइल नहीं है - सर्वर को उस यूआरएल को अलग करने के लिए प्रोग्राम किया गया है और पता है कि बॉडी डेटा के साथ क्या करना है- सेव यह आईडी 1234 के तहत एक मसौदा ईमेल के रूप में है

इसलिए यह निश्चित रूप से तरीकों से दूर करना संभव है, सिवाय इसके कि उनके चारों ओर विरासत विरासत के विशाल वजन को छोड़कर। यह बेहतर है कि आप उन्हें केवल उन चीज़ों के लिए उपयोग करें जिनकी आपको ज़रूरत है लेकिन बड़े पैमाने पर उन्हें अनदेखा करें और इसके बजाय अपनी चीज़ को काम में लाने के लिए आपको जो कुछ भी आवश्यक है उसका उपयोग करें। हमें अभी भी soecified के तरीकों की आवश्यकता है क्योंकि आपको यह याद रखना होगा कि उनका मतलब ब्राउज़र और सर्वर से है, जिसके ऊपर हमने अपने ऐप बनाए हैं। क्लाइंट साइड स्क्रिप्ट डेटा भेजने के लिए अंतर्निहित ब्राउज़र का उपयोग करना चाहता है, इसे एक ऐसी विधि का उपयोग करने की आवश्यकता है जो ब्राउज़र को ऐसा करने के लिए कहेगी- शायद एक POST क्योंकि GET यह सभी चर जानकारी url में पैक करता है और जिसकी लंबाई सीमा होती है बहुत सारे सर्वरों में। क्लाइंट सर्वर से एक लंबी प्रतिक्रिया चाहता है - एक हेड का उपयोग न करें क्योंकि उन्हें प्रतिक्रिया बॉडी बिल्कुल नहीं चाहिए।


1
मुझे एक फ्लैशबैक मिला "अगर आप जो लिखते हैं वह प्रोटोकॉल के अनुरूप नहीं है, तो यह केवल प्रोटोकॉल नहीं है" किसी ने मुझे बताया कि उनके पास "घर का नियम" था, जिसमें बिना कास्टेलिंग या एन-पासेंट पॉन कैप्चर के बिना शतरंज खेलना था। मैंने कहा, "यह एक दिलचस्प खेल है, लेकिन यह उन नियमों के बिना 'शतरंज' नहीं है।" खेल के नियमों को बदलें, और यह अब एक ही खेल नहीं है।
मोंटी हार्डर

4
आपने तरीकों या हेडर के बिना वर्तमान HTTP कैसे होगा इसके बारे में मंडलियां लिखी हैं (जबकि प्रश्न में हेडर के बारे में वास्तव में कुछ भी नहीं कहा गया है), लेकिन आप कभी नहीं कहते कि क्या तरीके हैं और क्या प्रोटोकॉल विधियों के बिना समान उद्देश्यों के लिए काम करेगा -जिसके बारे में सवाल था।
aaa

1
मुझे यह कहने की आवश्यकता क्यों है कि "" के लिए तरीके क्या हैं? इसके लिए एक कल्पना दस्तावेज है। HTTP कुछ भी जादू नहीं है, न ही FTP या SMTP या RTMP - वे सभी बस बाइट्स एक सॉकेट के नीचे जा रहे हैं, लेकिन यह ऑर्डर, प्रेजेंटेशन, नियम (प्रोटोकॉल) है जिसके अनुसार बाइट्स प्रोटोकॉल के अनुरूप होते हैं जो इसे बनाते हैं है। आपने उस प्रश्न में कुछ पढ़ा है जो मैंने नहीं किया है, लेकिन मुझे आपके प्रश्न का उत्तर देने में कोई आपत्ति नहीं है: क्या कोई विधि के बिना एक प्रोटोकॉल बना सकता है? - वास्तव में नहीं, लेकिन यह निर्भर करता है कि आप तरीकों से क्या मतलब है। HTTP तरीकों के साथ HTTP एकमात्र प्रोटोकॉल है, लेकिन सभी प्रोटोकॉल जिनके बारे में मैं सोच सकता हूं ..
कायुस जार्ड

.. सहभागिता के प्रतिरूपित तरीके जो मैं विधियों के रूप में संदर्भित करूंगा; उनके बिना वे एक प्रोटोकॉल नहीं होंगे और वे विश्वसनीय अंतर-प्रक्रिया / अंतर-सिस्टम संचार प्राप्त करने में सक्षम नहीं होंगे।
कायुस जार्ड

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

12

दूरस्थ प्रक्रिया कॉल के जेनेरिक सिद्धांतों के HTTP के एक विशिष्ट मामले के रूप में सोचा जा सकता है: आप सर्वर को अनुरोध में कुछ चर क्षेत्र के साथ क्या चाहते हैं, बता देते हैं। अब तक, 'वेब 2.0' की जटिल अन्तरक्रियाशीलता के कारण, ये वही सुविधाएँ अनुरोध पर हर क्षेत्र में छाई हुई हैं: URL, हेडर, निकाय-और प्रत्येक आब्जर्वर और ऐप उन्हें अपने तरीके से समझता है। हालाँकि, मूल रूप से वेब सरल था, स्थैतिक पृष्ठों का उपयोग किया गया था, और यह सोचा गया था कि HTTP तरीके अन्तरक्रियाशीलता के स्तर के लिए प्रदान करते हैं जो पर्याप्त होगा। विशेष रूप से, HTTP में बहुत सारे तरीके हैं जो शायद ही कभी उपयोग किए जाते हैं, यदि कभी हो, तो उनमें से कुछ में केवल REST के लिए प्रकाश धन्यवाद को देखते हुए। Eg PUT और DELETE REST से पहले रुग्ण थे, और TRACE और PATCH अभी भी अनदेखी नहीं हैं। Takeaway यह है कि HTTP का RPC का मॉडल '

REST ने जो आप प्रस्ताव कर रहे हैं, उसका ठीक उल्टा किया, यह ध्यान में रखते हुए कि HTTP विधियाँ अधिकांश ऐप्स के सामान्य CRUD उपयोग-मामलों की सेवा करती हैं, यदि PUT और DELETE वापस लाए जाते हैं।

यह भी ध्यान दें कि HTTP विधियों के पास शब्दार्थ हैं, जो ब्राउज़र और मिडलवेयर जैसे प्रॉक्सी सर्वर द्वारा सम्मानित किए जाते हैं: POST, PUT, DELETE और PATCH अनुरोधों के साइड इफेक्ट्स हो सकते हैं और इसके बेकार होने की संभावना नहीं है, इसलिए क्लाइंट-साइड ऐप और मिडलवेयर सावधानी बरतें उपयोगकर्ता से एक्सप्रेस कार्रवाई के बिना इन अनुरोधों को आग लगाने के लिए नहीं। व्यवहार में, खराब-डिज़ाइन किए गए वेब ऐप ने गैर-सुरक्षित कार्यों के लिए GET का उपयोग किया, और उदाहरण के लिए Google वेब त्वरक प्रीफ़ेचर ने ऐसी साइटों पर डेटा का गुच्छा हटाकर परेशानी का कारण बना दिया, इसलिए लॉन्च के तुरंत बाद इसका बीटा निलंबित कर दिया गया।

इसलिए, 'हम कर सकते हैं' सवाल का जवाब देने के लिए: निश्चित रूप से, आपको बस एक प्रोटोकॉल पर सहमत होने की आवश्यकता है जो सर्वर ऐप को बताएगा कि आप क्या कार्रवाई करना चाहते हैं, और फिर आप तर्क कहीं URL / बॉडी में डालते हैं - जैसे कि कार्रवाई के लिए लक्ष्य आइटम। क्रियाओं का सेट केवल विशिष्ट एप्लिकेशन द्वारा बाध्य होता है, इसलिए आपको एक एक्स्टेंसिबल प्रोटोकॉल की आवश्यकता होती है। लेकिन आपको क्लाइंट ऐप्स को यह बताना होगा कि कौन से अनुरोध सुरक्षित हैं, और शायद अन्य बारीकियों को ध्यान में रखें, जैसे कि कैश-कंट्रोल।


4
"PUT और DELETE REST से पहले रुग्ण थे" सच नहीं। आपको क्या लगता है कि WebDAV ने कैसे काम किया?
पैट्रिक मेवजेक

3
@PatrickMevzek हाँ, लेकिन WebDav का उपयोग काफी लोगों ने उन्हें कोमा की बजाय जीवित मानने के लिए किया था? ^ ^
फ्रैंक हॉपकिंस

1
@PatrickMevzek WebDAV व्यावहारिक रूप से HTTP से एक अलग प्रोटोकॉल है।
21

@duskwuff tools.ietf.org/html/rfc4918 "HTTP एक्सटेंशन्स फॉर वेब डिस्ट्रिब्यूटेड ऑथरिंग एंड वर्जनिंग (WebDAV)"। इतना अलग नहीं है, यह स्पष्ट रूप से इसके ऊपर है।
पैट्रिक मेवज़ेक

1
PATCH का उपयोग REST द्वारा आंशिक परिवर्तन (उर्फ अपडेट) को इंगित करने के लिए किया जाता है।
3

7

एक डेवलपर के रूप में मेरे व्यक्तिगत दृष्टिकोण से, यह एपीआई एंडपॉइंट्स को बहुत आसान बना सकता है। उदाहरण के लिए यदि मैं एक नियंत्रक लिखता हूं जो एक वेबसाइट पर उत्पादों का प्रबंधन करता है तो मैं एक ही URL का उपयोग कई अलग-अलग कार्यों को करने के लिए कर सकता हूं।

उदाहरण:

GET https://example.com/api/products/1234

इससे उत्पाद का विवरण 1234 प्राप्त होगा।


POST https://example.com/api/products/1234

यह अनुरोध शरीर में डेटा का उपयोग करके आईडी 1234 के साथ एक उत्पाद बनाएगा।


PUT https://example.com/api/products/1234

यह अनुरोध शरीर में डेटा के साथ उत्पाद 1234 को अपडेट करेगा।


DELETE https://example.com/api/products/1234

इससे ID 1234 वाला उत्पाद हट जाएगा।


मैं प्रत्येक ऑपरेशन के लिए अलग-अलग समापन बिंदु बना सकता था, लेकिन यह प्रक्रिया को जटिल बना देगा और इसे अन्य डेवलपर्स के लिए कम समझने योग्य बना देगा।


1
यह पूरी तरह से (या शायद के रूप में अच्छी तरह से) कुछ अन्य लोगों के रूप में सटीक सवाल का जवाब नहीं है, लेकिन यह व्यक्तिगत तरीकों के निरंतर उपयोग के लिए एक आधुनिक तर्क है। +1
18

6

HTTP प्रोटोकॉल में GET और POST जैसे तरीकों की क्या आवश्यकता है?

ऐसा लगता है कि आप पुराने दिनों को भूल गए जब HTTP सर्वर सिर्फ फाइलों की सेवा के लिए थे ; स्क्रिप्ट नहीं चलना, CGI, या उस तरह की गतिशील सामग्री बनाना।

अनुरोध तरीकों बुनियादी हैं मानकीकृत पर क्रियाओं के सेट क्या करना है उन फ़ाइलों के साथ ...

  • GET का मतलब है डाउनलोड
  • HEAD का मतलब है जानकारी प्राप्त करना
  • PUT का मतलब है अपलोड
  • DELETE का अर्थ है हटाना
  • POST का मतलब है डेटा भेजना
  • विकल्प का मतलब है कि मुझे बताएं कि मैं क्या कर सकता था

HTTP / 0.9 के दिन में, अनुरोध लाइन है प्रोटोकॉल का अनुरोध पैर में केवल एक चीज है; कोई अनुरोध हेडर नहीं, कोई प्रतिक्रिया हेडर नहीं। आप बस टाइप करें , प्रेस करें , सर्वर रिस्पांस बॉडी (यानी HTML कंटेंट) लौटाएगा, और ओके थैंक्स बाय (यानी कनेक्शन बंद करें)।GET /somefileEnter

अगर आपका मतलब सिर्फ यह पूछना है कि इसे इस तरह से क्यों बनाया गया ? मेरा उत्तर यह है क्योंकि यह मूल रूप से उस तरह के कंटेंट एक्सचेंज को संभालने के लिए लिखा गया था , जो यूजर्स के अनुरोध पर स्टैटिक एचटीएमएल फाइल परोस रहा था।

हालांकि, अगर आप आधुनिक अनुप्रयोग सर्वर में इन शब्दार्थों का इलाज करने के तरीके के बारे में पूछना चाहते हैं ...

क्या हम सिर्फ एक अनुरोध निकाय और एक प्रतिक्रिया निकाय का उपयोग करके HTTP प्रोटोकॉल को लागू नहीं कर सकते हैं?

क्या विभिन्न HTTP विधियों को लागू करना वास्तव में आवश्यक है?

मेरा उत्तर है: आप जो करना चाहते हैं वह करें, लेकिन इस बात का ध्यान रखें कि आपको प्रोटोकॉल की अपेक्षाओं को धता बताने वाले तरीके से आवेदन तर्क को लागू नहीं करना चाहिए : जीईटी जैसी अपेक्षाओं में डेटा नहीं बदलना चाहिए (या बहुत ही कम, कम से कम बेरोजगार परिणाम हैं ), HEAD का परिणाम GET जैसा ही होना चाहिए, लेकिन प्रतिक्रिया निकाय के बिना, PUT को लक्ष्य URI की सामग्री उपलब्ध करानी चाहिए (यदि सफल हुई)।

यदि आप इसके निहितार्थों पर ध्यान दिए बिना अपेक्षाओं के खिलाफ जाते हैं , तो विभिन्न अप्रिय चीजें होंगी, जैसे ...

  • जब आप डेटा जमा करने के उपयोग में GET विधि का उपयोग करते हैं, तो सर्वर आपके चेहरे में 414 " URI बहुत लंबी " त्रुटि थूक सकता है ।
  • जब आप डेटा संशोधन उपयोग में GET विधि का उपयोग करते हैं, तो आप पाएंगे कि संशोधन कभी-कभी उस समय नहीं होता जब उपयोगकर्ता कैशिंग प्रॉक्सी के पीछे होता है, या उपयोगकर्ता द्वारा URL को बुकमार्क से वापस बुलाने पर (या जब वेब क्रॉलर उस तक पहुंचते हैं) तो अप्रत्याशित संशोधन होंगे। ।
  • जब आप HEAD पद्धति का अनुचित तरीके से जवाब देते हैं, तो आप पाएंगे कि आपकी साइट पर स्वचालित साइट चेक टूल (जैसे wget --spider) जमानत है।
  • जब आप POST विधि को सामग्री डाउनलोड में शामिल करते हैं, तो आप पाएंगे कि बुकमार्क करना या यहां तक ​​कि ब्राउज़र में URL दर्ज करना भी काम नहीं करेगा।
  • और बहुत सारे...

" शुरुआत नियमों को जानता है, लेकिन दिग्गज अपवादों को जानते हैं। "

वैसे भी, आप कुछ संकीर्ण उपयोग के मामलों के नियमों के खिलाफ जाने के लिए कुछ वैध बहाने ढूंढ सकते हैं; लेकिन अपने शोध को करना सुनिश्चित करें और सभी संभावनाओं पर विचार करें। अन्यथा, आप अंतःसुविधा को समाप्त करने जा रहे हैं, और "उपयोगकर्ता अनुभवों" को बर्बाद कर रहे हैं।

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

मानक को लापरवाही से तोड़ने का मतलब यह भी है कि आप अपने उपयोगकर्ताओं पर भेदभाव लागू कर रहे हैं ।


3

यह सिद्धांत में सच है कि हम सभी जगह प्राप्त कर सकते हैं और यह काम की तरह होगा। कुछ सॉफ़्टवेयर भी अनुरोध निकाय के साथ GET का उपयोग करते हैं (मैं आपको elasticsearch / kibana देख रहा हूं)। यह निश्चित रूप से एक भयानक बात है।

सबसे महत्वपूर्ण कारण यह है कि अलग-अलग तरीकों के अलग-अलग शब्दार्थ हैं। कुछ सुरक्षित हैं, कुछ उदासीन हैं। कुछ दोनों हैं। देखें कौन-कौन से हैं

अन्य अनुप्रयोगों के साथ बातचीत करते समय यह महत्वपूर्ण है। जीईटी एंडपॉइंट्स का साइड इफेक्ट नहीं होना चाहिए। यह महत्वपूर्ण है जब Google आपका पक्ष क्रॉल कर रहा हो। PUT को माना जाता है कि इसका अर्थ यह है कि क्लाइंट विफलता के मामले में फिर से प्रयास करने के लिए स्वतंत्र है। यह POST का मामला नहीं है, जिसके कारण पोस्ट अनुरोध पर f5 दबाने पर ब्राउज़रों के पास बदसूरत पुष्टिकरण बॉक्स होना चाहिए।

देखें कि अगर आप जीएसटी का उपयोग कर सकते हैं तो आपको क्या करना चाहिए


1
एक शरीर के साथ प्राप्त वास्तव में कल्पना के अनुरूप है।
TRiG

दिलचस्प। यह 2014 में बदल गया था जैसे लगता है।
एबेन स्कोव पेडर्सन

1
एक शरीर के साथ मिलता है अनुरूप नहीं है, यह अब विशेष रूप से इसका उल्लंघन नहीं करता है। यह अब अपरिभाषित है, यही वजह है कि कुछ ग्राहक इसका समर्थन नहीं करते हैं। मेरा मानना ​​है कि CURL एक उदाहरण है
मंगल

2

आप GET, POST आदि को एक ही फ़ंक्शन के अधिभार के रूप में, या गेटर्स और सेटर के रूप में भी सोच सकते हैं।

GET_MyVar() एक इनपुट परम (उर्फ रिक्वेस्ट बॉडी) नहीं लेंगे, लेकिन कुछ लौटाते हैं।

POST_MyVar(string blah)इनपुट के साथ कुछ करता है (फिर से, अनुरोध निकाय) और कुछ वापस कर सकता है। (इसके लिए कम से कम एक प्रतिक्रिया कोड वापस करने की आवश्यकता है, ताकि हमें पता चले कि फ़ंक्शन चल गया है !! "

DELETE_MyVar() इसके अलावा शायद कुछ भी नहीं लेता है और उम्मीद है कि कुछ हटा दें।

हां, हम इसे सभी के साथ लागू कर सकते हैं:
MyVar(string Action, string? blah)

इस तरह हम सिर्फ एक कॉल को स्वीकार कर सकते हैं और फिर चुन सकते हैं कि कुछ अन्य पैरामीटर के आधार पर क्या करना है।

लेकिन इस दृष्टिकोण की एक उपयुक्तता यह है कि यह ब्राउज़र और सर्वर को इन चीजों के काम करने के तरीके को अनुकूलित करने की अनुमति देता है। उदाहरण के लिए, शायद सर्वर सभी अनुरोधों को अवरुद्ध करना चाहेगा Action==DELETE। हो सकता है कि ब्राउजर ऐसी चीजों को कैश करना चाहता हो जहां Action==GET.अगर नहीं, तो हर फंक्शन में हमें लिखना होगाif (Action==Delete) {return AngryFace}

प्रोटोकॉल के अनुसार सब कुछ लागू करने की कोई आवश्यकता नहीं है, लेकिन प्रोटोकॉल मूल रूप से नियमों का एक सेट है जिसे हम सभी ने पालन करने का फैसला किया है। इस तरह, मैं आसानी से अनुमान लगा सकता हूं कि आपकी साइट क्या करेगी, भले ही मैंने सर्वर नहीं देखा हो!


1

HTTP मेथड विभिन्न उद्देश्यों को पूरा करते हैं। सामान्य तौर पर, GETडाउनलोड के लिए है और POSTअपलोड के लिए है।

केवल एक अनुरोध निकाय और प्रतिक्रिया निकाय का उपयोग करके HTTP प्रोटोकॉल के भाग को लागू करने का एकमात्र तरीका लागू करना होगा POSTGETएक अनुरोध निकाय नहीं है। इसमें केवल हेडर के साथ ही अनुरोध है, लेकिन शरीर नहीं। यह केवल एक दस्तावेज़ को डाउनलोड करने के लिए एक अनुरोध है। POSTदोनों अनुरोध निकाय (फ़ाइल अपलोड) और एक प्रतिक्रिया निकाय (परिणाम दिखाने वाला दस्तावेज़) है।

तो क्या आप सिर्फ लागू कर सकते हैं POSTऔर किया जा सकता है? नहीं यदि आप चाहते हैं कि आपकी साइट मानक ब्राउज़रों में प्रयोग करने योग्य हो। डिफ़ॉल्ट अनुरोध प्रकार जो ब्राउज़र भेजता है GETPOSTअनुरोध आमतौर पर केवल तब भेजे जाते हैं जब वेब पेज में फॉर्म सबमिट किए जाते हैं या AJAX कॉल के लिए। केवल अगर यह विशेष सर्वर केवल AJAX कॉल के लिए उपयोग किया जा रहा था, और उपयोगकर्ताओं के लिए दिखाई देने वाले पृष्ठों के लिए नहीं, तो आप POSTकेवल दूर हो सकते हैं ।

ब्राउज़र कभी-कभी यह HEADजांचने के लिए अनुरोध भेजते हैं कि क्या कोई दस्तावेज़ पिछली बार डाउनलोड करने के बाद से बदल गया है, इसलिए इसे कम से कम लागू करने की सलाह दी जाएगी।

किसी भी मामले में, खरोंच से आपकी साइट के लिए वेब सर्वर को लागू करने का एक अच्छा कारण नहीं है। HTTP प्रोटोकॉल जटिल है। विभिन्न तरीकों के अलावा आपको पाइपलाइनिंग और चंक किए गए अनुरोधों को भी लागू करना होगा। Apache, Nginx, या IIS जैसे वेब सर्वर के शीर्ष पर अपने वेब एप्लिकेशन को बनाना बहुत आसान है जो आपके लिए HTTP प्रोटोकॉल को संभालता है। आप सर्वलेट्स का उल्लेख करते हैं, इसलिए शायद आपको टॉमकैट या जेबॉस वेब सर्वर का उपयोग करना चाहिए जो सर्वलेट चलाते हैं।


मुझे लगता है कि यह सवाल ए वेबसाइट की तुलना में एक गंभीर स्तर पर है। नहीं "मुझे GET और POST क्यों लागू करना है," लेकिन "ब्राउज़र GET और POST को क्यों लागू करते हैं"?
मंगल

@ मार्स यदि ऐसा है, तो इस साइट के लिए सवाल ऑन-टॉपिक नहीं है।
स्टीफन Ostermiller

यह एक इतिहास का प्रश्न है जो मुझे लगता है, और ऐसा लगता है कि यह उन मुद्दों के अंतर्गत आता है जो संपूर्ण वेबसाइटों को प्रभावित करते हैं (प्रश्न पूछें पृष्ठ से)। लेकिन ओपी गायब हो गया, इसलिए मुझे लगता है कि यह हमेशा एक रहस्य होगा
मंगल

0

आप सही हैं, हम बस यही कर सकते हैं, GET, POST, PUT इत्यादि सिर्फ ऐतिहासिक सम्मेलन हैं अगर मैंने अपना रास्ता बना लिया तो HTTP को केवल POST विधि से जोड़ दिया जाएगा और कुछ नहीं, हालांकि मुझे यह स्वीकार करना होगा कि GET को खत्म करना एक बहुत बड़ा उपक्रम होगा, ऐसा नहीं किया जा सकता है, घोड़े ने पहले ही उस पर बोल्ट लगा दिया है


1
"GET, POST, PUT इत्यादि केवल ऐतिहासिक सम्मेलन हैं" - वे कन्वेंशन नहीं हैं। उनके पास सटीक व्यवहार है, और इसके अलावा, उनके पास अलग-अलग व्यवहार हैं।
जोर्ग डब्ल्यू मित्तग

एक वेब एपीआई डेवलपर के रूप में, मैं आसानी से POSTs के साथ GETs को इंटरचेंज कर सकता हूं और इसके विपरीत, मेरे जवाब का आधार है, ईमानदार होना POST के साथ संघर्ष करने के लिए कम मुद्दे हैं और अगर मेरे पास आईडी था, तो मैं अपने सभी एपीआई तरीकों को जीएसटी तरीके से बनाऊंगा
user104723

-1

आपका प्रस्तावित प्रोटोकॉल हैकर्स के खिलाफ काफी कम सुरक्षित होगा।

एक कारण है कि वेबसाइटें चरों और इस तरह के URL के बारे में जानकारी संग्रहीत करने से दूर हो गई हैं, और यह कारण सरल है: यह हमलावरों को आपके सिस्टम पर हमला करने का एक बहुत ही सरल तरीका देता है। प्लेनटेक्स्ट यूआरएल की जानकारी को देखकर, वे फैशन को निर्धारित कर सकते हैं कि आपके वेब सर्वर को भेजे गए डेटा का निर्माण किया गया है; फिर वे इस जानकारी का उपयोग अपने सर्वर पर एक विशेष रूप से निर्मित URL का उपयोग करके किसी हमले को अंजाम देने के लिए कर सकते हैं जो उन्हें आपके सर्वर पर दुर्भावनापूर्ण कोड या डेटा इंजेक्ट करने की अनुमति देता है।


सिवाय इसके कि HTTPS के तहत, GET की सामग्री नेटवर्क पर बिल्कुल भी प्लेनटेक्स्ट में नहीं है ... और हमलावर किन्नर भाग्य, पाशविक बल या अन्य टेकनीक द्वारा दुर्भावनापूर्ण कोड को इंजेक्ट कर सकते हैं, उन्हें पहले से ही कुछ भी देखने की आवश्यकता नहीं है।
पैट्रिक मेवजेक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.