कृपया ध्यान दें कि यह उत्तर पहली बार लिखे जाने के बाद से प्रश्न बदल गया है / स्पष्ट कर दिया गया है। प्रश्न के नवीनतम पुनरावृत्ति के लिए एक और प्रतिक्रिया दूसरी क्षैतिज नियम के बाद है
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 में पैक करता है और जिसकी लंबाई सीमा होती है बहुत सारे सर्वरों में। क्लाइंट सर्वर से एक लंबी प्रतिक्रिया चाहता है - एक हेड का उपयोग न करें क्योंकि उन्हें प्रतिक्रिया बॉडी बिल्कुल नहीं चाहिए।