HTTP: प्रोटोकॉल हर वेब डेवलपर पता होना चाहिए-भाग 1

() translation by (you can also view the original English article)

HTTP हाइपर टेक्स्ट ट्रांसफ़र प्रोटोकॉल के लिए खड़ा है. यह एक राज्य है, अनुप्रयोग परत वितरित सिस्टम के बीच संवाद स्थापित करने के लिए प्रोटोकॉल, और आधुनिक वेब का आधार है । एक वेब डेवलपर के रूप में, हम सब इस प्रोटोकॉल की एक मजबूत समझ होना चाहिए ।

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

हालांकि मैं कुछ हेडर से संबंधित विवरण का उल्लेख करेंगे, इसके बजाय में गहराई से कवरेज के लिए rfc (rfc २६१६) से परामर्श करने के लिए सबसे अच्छा है । मैं RFC के विशिष्ट भागों के लिए लेख भर में इंगित किया जाएगा ।

HTTP मूल बातें

HTTP मेजबान और ग्राहकों की एक किस्म के बीच संचार के लिए अनुमति देता है, और नेटवर्क विंयास का एक मिश्रण का समर्थन करता है ।

यह संभव बनाने के लिए, यह एक विशेष प्रणाली के बारे में बहुत कम है, और अलग संदेश एक्सचेंजों के बीच राज्य नहीं रखता है ।

यह HTTP एक ख़ामोश प्रोटोकॉल बनाता है । संचार आमतौर पर TCP/IP पर जगह लेता है, लेकिन किसी भी विश्वसनीय परिवहन इस्तेमाल किया जा सकता है । TCP/IP के लिए डिफ़ॉल्ट पोर्ट ८० है, लेकिन अंय पोर्ट भी उपयोग किया जा सकता है ।

कस्टम शीर्ष लेख भी बनाया और ग्राहक द्वारा भेजा जा सकता है ।

एक मेजबान और एक ग्राहक के बीच संचार होता है, एक अनुरोध के माध्यम/ क्लाइंट किसी http अनुरोध संदेश, जो एक http प्रतिसाद संदेश के माध्यम से बदले में सेवा है प्रारंभ करता है । हम इस मौलिक संदेश-युग्म को अगले भाग में देखेंगे ।

प्रोटोकॉल के वर्तमान संस्करण HTTP/1.1, जो पिछले १.० संस्करण के लिए कुछ अतिरिक्त सुविधाएं जोड़ता है । इनमें से सबसे महत्वपूर्ण, मेरी राय में, लगातार कनेक्शन भी शामिल है, हिस्सा स्थानांतरण कोडिंग और ठीक-कैशिंग हेडर । हम संक्षेप में इस लेख में इन सुविधाओं पर संपर्क करेंगे; में गहराई से कवरेज भाग दो में प्रदान की जाएगी ।

Url

वेब संचार के दिल में अनुरोध संदेश है, जो वर्दी संसाधन लोकेटर (यूआरएल) के माध्यम से भेजा जाता है । मुझे यकीन है कि आप यूआरएल से पहले से ही परिचित हैं, लेकिन पूर्णता के लिए, मैं इसे यहां शामिल हूं हूं । url में एक साधारण संरचना होती है, जिसमें निंन घटक होते हैं:

प्रोटोकॉल आमतौर पर http है, लेकिन यह भी सुरक्षित संचार के लिए https हो सकता है । डिफ़ॉल्ट पोर्ट ८० है, लेकिन एक स्पष्ट रूप से सेट किया जा सकता, के रूप में ऊपर छवि में सचित्र । संसाधन पथ सर्वर पर संसाधन के लिए स्थानीय पथ है ।

Verbs

वहां भी कर रहे है वेब प्रॉक्सी डिबगिंग, OSX के लिए खिड़कियों और चार्ल्स प्रॉक्सी पर सारंगी की तरह ।

url के साथ हम संवाद करना चाहते हैं जो विशेष होस्ट की पहचान प्रकट, लेकिन होस्ट पर किया जाना चाहिए जो क्रिया HTTP क्रियाएँ के माध्यम से निर्दिष्ट किया गया है । बेशक, वहां कई कार्यों कि एक ग्राहक मेजबान की तरह प्रदर्शन करने के लिए कर रहे हैं । HTTP कुछ है कि अनिवार्य है कि आवेदनों के सभी प्रकार के लिए सार्वभौमिक लागू कर रहे है पर कब्जा औपचारिक रूप से किया गया है ।

ये अनुरोध क्रिया हैं:

प्राप्त करें: मौजूदा संसाधन लाएं । URL में सभी आवश्यक जानकारी है जो सर्वर को ढूंढने और संसाधन को लौटाने की आवश्यकता होती है ।
पोस्ट: एक नया संसाधन बनाएं । पोस्ट अनुरोधों आमतौर पर नए संसाधन के लिए डेटा निर्दिष्ट करता है कि एक पेलोड ले ।
रखें: किसी मौजूदा संसाधन का अद्यतन करें । पेलोड संसाधन के लिए अद्यतित डेटा हो सकता है ।
हटाएं: किसी मौजूदा संसाधन को हटाएं ।

ऊपर चार verbs सबसे लोकप्रिय हैं, और सबसे उपकरणों और चौखटे स्पष्ट रूप से इन अनुरोध verbs बेनकाब । डाल और हटाएँ कभी-कभार पोस्ट क्रिया के विशेष संस्करण माने जाते हैं, और उन्हें सटीक कार्रवाई वाले पेलोड के साथ पोस्ट अनुरोधों के रूप में पैक किया जा सकता है: बनाएँ, अद्यतन करें या हटाएँ.

HTTP भी समर्थन करता है कि कुछ कम इस्तेमाल किया क्रियाएँ कर रहे हैं:

सिर: यह पाने के लिए समान है, लेकिन संदेश शरीर के बिना । यह एक विशेष संसाधन के लिए सर्वर हेडर पुनः प्राप्त करने के लिए प्रयोग किया जाता है, आम तौर पर जांच करने के लिए अगर संसाधन बदल गया है, टाइमस्टैंप के माध्यम से ।
ट्रेस: एक अनुरोध सर्वर से राउंड ट्रिप करने के लिए लेता है hops पुनर्प्राप्त करने के लिए उपयोग किया जाता है । प्रत्येक मध्यवर्ती प्रॉक्सी या गेटवे अपने IP या DNS नाम के माध्यम से शीर्ष लेख फ़ील्ड में इंजेक्ट होगा । यह नैदानिक प्रयोजनों के लिए इस्तेमाल किया जा सकता है ।
विकल्प: सर्वर क्षमताओं को पुनर्प्राप्त करने के लिए प्रयुक्त । क्लाइंट-साइड पर, यह क्या सर्वर का समर्थन कर सकते हैं पर आधारित अनुरोध को संशोधित करने के लिए उपयोग किया जा सकता है ।

स्थिति कोड

url और क्रियाएँ के साथ, क्लाइंट सर्वर के लिए अनुरोध प्रारंभ कर सकते हैं । बदले में, सर्वर स्थिति कोड और संदेश पेलोड के साथ प्रतिक्रिया करता है । स्थिति कोड महत्वपूर्ण है और क्लाइंट सर्वर प्रतिसाद की व्याख्या करने के लिए कैसे कहता है । HTTP युक्ति विशिष्ट प्रकार की प्रतिक्रियाओं के लिए कुछ संख्या श्रेणियों को परिभाषित करता है:

1xx: जानकारी संदेश

सभी HTTP/1.1 क्लाइंट स्थानांतरण एन्कोडिंग शीर्ष लेख को स्वीकार करने के लिए आवश्यक हैं ।

कोड के इस वर्ग HTTP/1.1 में पेश किया गया था और विशुद्ध रूप से अनंतिम है । सर्वर एक अपेक्षा भेज सकते हैं: १००-संदेश जारी रखने के लिए, अनुरोध के शेष भेजना जारी रखने के लिए क्लाइंट बता रहा है, या यदि यह पहले से ही इसे भेज दिया है की उपेक्षा । HTTP/1.0 क्लाइंट इस शीर्षलेख को अनदेखा करने वाले हैं ।

2xx: सफल

यह अनुरोध सफलतापूर्वक संसाधित किया गया था कि क्लाइंट कहता है । सबसे आम कोड २०० ठीक है । GET अनुरोध के लिए, सर्वर संसाधन संदेश के मुख्य भाग में भेजता है । वहां अंय कम बार इस्तेमाल किया कोड हैं:

२०२ स्वीकार किए जाते हैं: अनुरोध स्वीकार कर लिया गया था लेकिन संसाधन में प्रतिसाद शामिल नहीं हो सकता है । यह सर्वर साइड पर async प्रोसेसिंग के लिए उपयोगी है । सर्वर मॉनिटरिंग के लिए जानकारी भेजने के लिए चुन सकते हैं ।
२०४ कोई सामग्री नहीं: प्रतिसाद में कोई संदेश का मुख्य भाग है ।
२०५ सामग्री रीसेट करें: इसके दस्तावेज़ दृश्य को रीसेट करने के लिए क्लाइंट को इंगित करता है ।
२०६ आंशिक सामग्री: इंगित करता है कि प्रत्युत्तर में केवल आंशिक सामग्री है । अतिरिक्त शीर्ष लेख सटीक श्रेणी और सामग्री समय सीमा समाप्ति जानकारी इंगित करते हैं ।

3xx: पुनर्निर्देशन

४०४ इंगित करता है कि संसाधन अमान्य है और सर्वर पर मौजूद नहीं है ।

यह अतिरिक्त क्रिया करने के लिए क्लाइंट की आवश्यकता है । सबसे आम उपयोग-मामले संसाधन लाने के क्रम में एक अलग यूआरएल के लिए कूद करने के लिए है ।

३०१ स्थायी रूप से स्थानांतरित: संसाधन अब एक नया URL पर स्थित है ।
३०३ अंय देखें: संसाधन अस्थाई रूप से एक नया URL पर स्थित है । स्थान प्रतिक्रिया शीर्षलेख में अस्थाई URL होता है ।
३०४ नहीं संशोधित: सर्वर संसाधन नहीं बदला गया है और क्लाइंट इसकी कैश्ड प्रतिलिपि का उपयोग करना चाहिए कि निर्धारित किया गया है । यह तथ्य यह है कि ग्राहक ETag (Enttity टैग) जानकारी है कि सामग्री का एक हैश है भेज रहा है पर निर्भर करता है । सर्वर संशोधन के लिए जाँच करने के लिए अपने स्वयं परिकलित ETag के साथ इस तुलना करता है ।

4xx: क्लाइंट त्रुटि

इन कोड्स का उपयोग किया जाता है जब सर्वर सोचता है कि क्लाइंट त्रुटि पर है, या तो कोई अमान्य संसाधन का अनुरोध कर रहा है या एक ग़लत अनुरोध कर रहा है । इस वर्ग में सबसे लोकप्रिय कोड ४०४ नहीं मिला है, जो मुझे लगता है कि हर किसी के साथ की पहचान करेगा । ४०४ इंगित करता है कि संसाधन अमान्य है और सर्वर पर मौजूद नहीं है । इस वर्ग में अंय कोड में शामिल हैं:

४०० ग़लत अनुरोध: अनुरोध विकृत किया गया था ।
४०१ अनधिकृत: अनुरोध प्रमाणन की आवश्यकता है । क्लाइंट अनुरोध प्राधिकरण शीर्ष लेख के साथ दोहरा सकते हैं । क्लाइंट पहले से ही प्राधिकरण शीर्ष लेख शामिल है, तो क्रेडेंशियल्स गलत थे ।
४०३ निषिद्ध: सर्वर संसाधन के लिए पहुँच निषेध है ।
४०५ पद्धति की अनुमति नहीं है: अनुरोध पंक्ति में उपयोग किया गया अमांय HTTP क्रिया, या सर्वर उस क्रिया का समर्थन नहीं करता ।
४०९ विरोध: क्लाइंट क्लाइंट के टाइमस्टैंप से नया है जो किसी संसाधन को संशोधित करने का प्रयास कर रहा है, क्योंकि सर्वर अनुरोध को पूरा नहीं कर सका । विरोध ज्यादातर एक संसाधन पर सहयोगात्मक संपादन के दौरान डाल अनुरोधों के लिए उठता है ।

5xx: सर्वर त्रुटि

इस वर्ग के कोड्स का उपयोग अनुरोध को संसाधित करते समय सर्वर विफलता को इंगित करने के लिए किया जाता है । सबसे अधिक इस्तेमाल किया त्रुटि कोड आंतरिक सर्वर त्रुटि ५०० है । इस वर्ग में दूसरों रहे हैं:

५०१ लागू नहीं किया गया: सर्वर अभी तक अनुरोधित कार्यक्षमता का समर्थन नहीं करता है ।
५०३ सेवा उपलब्ध नहीं: यह हो सकता है यदि सर्वर पर कोई आंतरिक सिस्टम विफल हो गया है या सर्वर ओवरलोडेड है । सामांयतया, सर्वर भी प्रतिसाद नहीं देगा और अनुरोध समयबाह्य होगा ।

अनुरोध और प्रत्युत्तर संदेश स्वरूप

अब तक, हमने देखा है कि यूआरएल, verbs और स्थिति कोड एक HTTP अनुरोध के मौलिक टुकड़े/

आइए अब इन संदेशों की सामग्री को देखें । HTTP विनिर्देश बताता है कि अनुरोध या प्रतिसाद संदेश निम्न जेनेरिक संरचना है:

1	message = <start-line> *(<message-header>) CRLF [<message-body>] <start-line> = Request-Line \| Status-Line <message-header> = Field-Name ':' Field-Value

यह संदेश हेडर और शरीर के बीच एक नई लाइन जगह अनिवार्य है । संदेश में एक या अधिक शीर्ष लेख शामिल हो सकते हैं, जिनमें से मोटे तौर पर वर्गीकृत किए गए हैं:

सामांय शीर्षलेख: जो अनुरोध और प्रतिसाद संदेश दोनों के लिए लागू होते हैं ।
विशिष्ट शीर्षलेख का अनुरोध करें ।
प्रतिक्रिया विशिष्ट हेडर ।
एंटिटी शीर्ष लेख ।

संदेश का मुख्य भाग पूर्ण एंटिटी डेटा हो सकता है, या यदि खंड एन्कोडिंग (स्थानांतरण-एन्कोडिंग: खंड) का उपयोग किया जाता है, तो यह piecemeal हो सकता है । सभी HTTP/1.1 क्लाइंट स्थानांतरण एन्कोडिंग शीर्ष लेख को स्वीकार करने के लिए आवश्यक हैं ।

सामांय शीर्षलेख

अनुरोध और प्रतिसाद संदेश दोनों द्वारा साझा किए गए हैं जो कुछ शीर्ष लेख (सामान्य शीर्ष लेख) हैं:

1	general-header = Cache-Control \| Connection \| Date \| Pragma \| Trailer \| Transfer-Encoding \| Upgrade \| Via \| Warning

हम पहले से ही इन हेडर के कुछ देखा है, विशेष रूप से और हस्तांतरण के माध्यम से एंकोडिंग । हम कैश-नियंत्रण और भाग दो में कनेक्शन को कवर किया जाएगा ।

स्थिति कोड महत्वपूर्ण है और क्लाइंट सर्वर प्रतिसाद की व्याख्या करने के लिए कैसे कहता है ।

शीर्षक के माध्यम से एक ट्रेस संदेश में प्रयोग किया जाता है और सभी आंतरायिक परदे के ऊपर और गेटवे द्वारा अद्यतन
Pragma एक कस्टम हैडर माना जाता है और कार्यांवयन विशिष्ट हेडर शामिल करने के लिए इस्तेमाल किया जा सकता है । सबसे अधिक इस्तेमाल किया pragma-निर्देश pragma है: नहीं, कैश, जो वास्तव में कैश नियंत्रण है: नहीं-कैश के तहत HTTP/ यह लेख के भाग 2 में शामिल किया जाएगा ।
दिनांक शीर्ष लेख फ़ील्ड अनुरोध/प्रत्युत्तर संदेश टाइमस्टैम्प के लिए उपयोग किया जाता है
उंनयन प्रोटोकॉल स्विच और एक नए प्रोटोकॉल के लिए एक चिकनी संक्रमण की अनुमति के लिए प्रयोग किया जाता है ।
स्थानांतरण-एंकोडिंग आमतौर पर स्थानांतरण-एंकोडिंग: अंश मान के साथ छोटे भागों में प्रतिक्रिया को तोड़ने के लिए उपयोग किया जाता है । यह HTTP/1.1 में एक नया शीर्षक है और बजाय एक बड़ा पेलोड के ग्राहक के लिए प्रतिक्रिया के स्ट्रीमिंग के लिए अनुमति देता है ।

एंटिटी शीर्ष लेख

अनुरोध और प्रतिसाद संदेश में सामग्री (उर्फ संदेश का मुख्य भाग या एंटिटी) के बारे में मेटा-जानकारी प्रदान करने के लिए एंटिटी शीर्ष लेख भी शामिल हो सकते हैं । इन शीर्ष लेखों में शामिल हैं:

1	entity-header = Allow \| Content-Encoding \| Content-Language \| Content-Length \| Content-Location \| Content-MD5 \| Content-Range \| Content-Type \| Expires \| Last-Modified

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

समयसीमा समाप्त शीर्ष लेख जब निकाय समयसीमा समाप्त होने का एक टाइमस्टैंप इंगित करता है । दिलचस्प है, एक "कभी नहीं समाप्त" निकाय भविष्य में एक वर्ष के टाइमस्टैंप के साथ भेजा जाता है । अंतिम संशोधित शीर्ष लेख निकाय के लिए अंतिम संशोधन टाइमस्टैंप इंगित करता है ।

कस्टम हेडर भी बनाया और ग्राहक द्वारा भेजा जा सकता है; वे HTTP प्रोटोकॉल द्वारा निकाय शीर्ष लेख के रूप में माना जाएगा ।

यह वास्तव में एक विस्तार प्रणाली है, और कुछ क्लाइंट सर्वर implementations विशेष रूप से इन विस्तार हेडर पर संवाद करने के लिए चुन सकते हैं । हालांकि HTTP कस्टम हेडर का समर्थन करता है, क्या यह वास्तव में लगता है के लिए अनुरोध और प्रतिक्रिया हेडर, जो हम अगले कवर कर रहे हैं ।

अनुरोध स्वरूप

अनुरोध संदेश समान जेनेरिक संरचना के रूप में ऊपर, अनुरोध लाइन जो की तरह दिखता है के अलावा है:

1	Request-Line = Method SP URI SP HTTP-Version CRLF Method = "OPTIONS" \| "HEAD" \| "GET" \| "POST" \| "PUT" \| "DELETE" \| "TRACE"

एसपी के टोकन के बीच स्पेस सेपरेटर है । http-संस्करण "http/1.1" के रूप में निर्दिष्ट है और फिर एक नई लाइन के बाद । इस प्रकार, एक ठेठ अनुरोध संदेश की तरह लग सकता है:

1	GET /articles/http-basics HTTP/1.1 Host: www.articles.com Connection: keep-alive Cache-Control: no-cache Pragma: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8

अनुरोध पंक्ति कई अनुरोध शीर्ष लेख के बाद नोट करें । होस्ट शीर्ष लेख HTTP/1.1 क्लाइंट के लिए अनिवार्य है । अनुरोध प्राप्त करें संदेश का मुख्य भाग नहीं है, लेकिन पोस्ट अनुरोध में मुख्य भाग में पोस्ट डेटा हो सकते हैं ।

अनुरोध शीर्ष लेख अनुरोध संदेश के संशोधक के रूप में कार्य करते हैं । ज्ञात अनुरोध शीर्ष लेख की पूरी सूची बहुत लंबा नहीं है, और नीचे दी गई है । अज्ञात शीर्ष लेख निकाय-शीर्ष लेख फ़ील्ड के रूप में माना जाता है ।

 request-header = Accept                                   | Accept-Charset                    | Accept-Encoding                   | Accept-Language                   | Authorization                     | Expect                            | From                              | Host                              | If-Match                          | If-Modified-Since                 | If-None-Match                     | If-Range                          | If-Unmodified-Since                | Max-Forwards                       | Proxy-Authorization                | Range                              | Referer                            | TE                                 | User-Agent

स्वीकार प्रीसेट शीर्ष लेख स्वीकार्य मीडिया-प्रकार, भाषा और वर्ण सेट क्लाइंट पर इंगित करते हैं । से, होस्ट, संदर्भकर्ता और उपयोगकर्ता-एजेंट अनुरोध प्रारंभ किया गया क्लाइंट के बारे में विवरण की पहचान करें । if-निर्धारित शीर्ष लेख एक अनुरोध अधिक सशर्त बनाने के लिए उपयोग किया जाता है, और सर्वर संसाधन केवल तभी शर्त से मेल खाता है । अंयथा, यह एक ३०४ संशोधित नहीं देता है । शर्त एक टाइमस्टैंप या एक ETag (निकाय के एक हैश) पर आधारित हो सकता है ।

प्रतिसाद स्वरूप

प्रतिसाद स्वरूप, स्थिति पंक्ति और शीर्ष लेख को छोड़कर, अनुरोध संदेश के समान है । स्थिति पंक्ति में निंन संरचना है:

1	Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

http-संस्करण http/1.1 के रूप में भेजा गया है
स्थिति-कोड पहले से चर्चा की कई स्थितियों में से एक है ।
कारण-वाक्यांश स्थिति कोड का एक मानव पठनीय संस्करण है ।

एक सफल प्रतिक्रिया के लिए एक ठेठ स्थिति रेखा की तरह लग सकता है:

1	HTTP/1.1 200 OK

प्रतिक्रिया हेडर भी काफी सीमित हैं, और पूर्ण सेट नीचे दिया गया है:

1	response-header = Accept-Ranges \| Age \| ETag \| Location \| Proxy-Authenticate \| Retry-After \| Server \| Vary \| WWW-Authenticate

सर्वर पर संदेश जनरेट होने के बाद आयु सेकंड में समय है ।
ETag निकाय के MD5 हैश है और संशोधनों के लिए जांच करने के लिए इस्तेमाल किया ।
स्थान का उपयोग पुनर्निर्देशन भेजते समय किया जाता है और इसमें नया URL होता है.
सर्वर संदेश जनरेट करने वाले सर्वर की पहचान करता है ।

यह इस बिंदु तक सिद्धांत का एक बहुत हो गया है, तो मैं तुंहें नींद आंखों के लिए दोषी नहीं होगा । अगले वर्गों में, हम और अधिक व्यावहारिक मिल जाएगा और उपकरणों, चौखटे और पुस्तकालयों का एक सर्वेक्षण ले ।

HTTP ट्रैफ़िक देखने के लिए उपकरण

HTTP संचार की निगरानी करने के लिए उपलब्ध उपकरणों की एक संख्या है । यहां, हम और अधिक लोकप्रिय उपकरणों के कुछ सूची ।

निस्संदेह, क्रोम/Webkit निरीक्षक वेब डेवलपर्स के बीच एक पसंदीदा है:

वहां भी कर रहे है वेब प्रॉक्सी डिबगिंग, OSX के लिए खिड़कियों और चार्ल्स प्रॉक्सी पर सारंगी की तरह । मेरे सहयोगी, Rey बांगो इस विषय पर एक उत्कृष्ट लेख लिखा था ।

कमांड लाइन के लिए, हम की तरह उपयोगिताओं है कर्ल, tcpdump और HTTP यातायात की निगरानी के लिए tshark ।

वेब फ़्रेमवर्क्स और लाइब्रेरीज़ में HTTP का उपयोग करना

अब जब कि हम अनुरोध/प्रतिक्रिया संदेश में देखा है, यह समय है कि हम सीखते है कि कैसे पुस्तकालयों और चौखटे यह एक एपीआई के रूप में बेनकाब । हम नोड के लिए ExpressJS का उपयोग करेंगे, पटरियों पर रूबी, और हमारे उदाहरण के रूप में jQuery Ajax ।

ExpressJS

यदि आप NodeJS में वेब सर्वर का निर्माण कर रहे हैं, संभावना अधिक है कि आप ExpressJS माना जाता है । ExpressJS मूलतः एक रूबी वेब फ्रेमवर्क से प्रेरित था, सिनात्रा कहा जाता है । जैसा कि उंमीद थी, एपीआई भी समान रूप से प्रभावित है ।

क्योंकि हम एक सर्वर साइड फ्रेमवर्क के साथ काम कर रहे हैं, वहां दो प्राथमिक कार्य जब HTTP संदेश के साथ काम कर रहे हैं:

URL अंशों और अनुरोध शीर्ष लेख पढ़ें ।
प्रतिसाद शीर्ष लेख और मुख्य भाग लिखें

समझना HTTP दो समापन के बीच एक स्वच्छ, सरल और स्थिर इंटरफेस होने के लिए महत्वपूर्ण है ।

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

अनुरोध शरीर: अनुरोध शरीर प्राप्त करें ।
अनुरोध. query: URL का क्वेरी अंश प्राप्त करें ।
अनुरोध originalUrl
अनुरोध. host: होस्ट हैडर फ़ील्ड पढ़ता है ।
अनुरोध. स्वीकार करता है: ग्राहक पक्ष पर स्वीकार्य MIME-प्रकार पढ़ता है ।
अनुरोध या अनुरोध. header: किसी भी शीर्ष लेख फ़ील्ड तर्क के रूप में पारित पढ़ें ।

क्लाइंट के लिए बाहर के रास्ते पर, ExpressJS निम्न प्रतिसाद API प्रदान करता है:

res. स्थिति: एक स्पष्ट स्थिति कोड सेट करें ।
res. set: एक विशिष्ट प्रतिसाद शीर्ष लेख सेट करें ।
res. send: भेजें HTML, JSON या एक octet-स्ट्रीम ।
res. sendFile: क्लाइंट के लिए एक फ़ाइल स्थानांतरण ।
res. रैंडर: एक एक्सप्रेस दृश्य टेम्पलेट रेंडर ।
res. पुनर्निर्देशन: किसी भिंन मार्ग पर पुनर्निर्देशित करें । Express स्वचालित रूप से ३०२ का डिफ़ॉल्ट पुनर्निर्देशन कोड जोड़ता है ।

पटरियों पर रूबी

अनुरोध और प्रतिक्रिया संदेश ज्यादातर समान हैं, पहली पंक्ति और संदेश शीर्ष लेखों को छोड़कर ।

रेल में, ActionController और ActionDispatch मॉड्यूल अनुरोध और प्रतिक्रिया संदेश हैंडलिंग के लिए एपीआई प्रदान करते हैं ।

ActionController अनुरोध URL को पढ़ने के लिए एक उच्च स्तर एपीआई प्रदान करता है, आउटपुट प्रदान और एक अलग अंत बिंदु को अनुप्रेषित । एक अंतिम-बिंदु (उर्फ मार्ग) एक क्रिया पद्धति के रूप में संचालित किया जाता है । एक क्रिया-विधि के अंदर आवश्यक संदर्भ जानकारी के अधिकांश अनुरोध, प्रतिक्रिया और परम पिंड वस्तुओं के माध्यम से प्रदान की जाती है ।

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

ActionDispatch ActionDispatch के माध्यम से अनुरोध/प्रतिक्रिया संदेश के लिए ठीक दानेदार उपयोग प्रदान करता है:: अनुरोध और ActionDispatch:: प्रतिक्रिया कक्षाएं । यह अनुरोध के प्रकार की जांच करने के लिए क्वेरी विधियों का एक सेट दिखाता है (get? (), पोस्ट? (), head? (), स्थानीय? ()). अनुरोध हेडर सीधे अनुरोध के माध्यम से पहुँचा जा सकता है. हेडर () विधि.

प्रतिक्रिया ओर, यह कुकीज़ सेट करने के लिए विधियाँ प्रदान करता है (), स्थान = () और स्थिति = (). आप साहसी महसूस करते हैं, तो आप भी शरीर = () सेट कर सकते हैं और रेल प्रतिपादन प्रणाली बाईपास.

jQuery Ajax

क्योंकि jQuery मुख्य रूप से एक ग्राहक के पक्ष पुस्तकालय है, अपने Ajax एपीआई एक सर्वर साइड फ्रेमवर्क के विपरीत प्रदान करता है । दूसरे शब्दों में, यह आप प्रतिक्रिया संदेश पढ़ने के लिए और अनुरोध संदेश को संशोधित करने की अनुमति देता है । jquery jquery के द्वारा एक सरल एपीआई को उजागर करता है । ajax (सेटिंग्स):

beforeSend कॉलबैक के साथ एक सेटिंग ऑब्जेक्ट पास करके, हम अनुरोध शीर्ष लेखों को संशोधित कर सकते हैं । कॉलबैक jqXHR (jQuery XMLHttpRequest) ऑब्जेक्ट है कि एक विधि, बुलाया setRequestHeader () हेडर सेट को उजागर करता है ।

1	$.ajax({ url: 'http://www.articles.com/latest', type: 'GET', beforeSend: function (jqXHR) { jqXHR.setRequestHeader('Accepts-Language', 'en-US,en'); } });

jqXHR ऑब्जेक्ट भी jqXHR. getResponseHeader () के साथ प्रतिक्रिया शीर्ष लेख को पढ़ने के लिए उपयोग किया जा सकता है ।
आप विभिन्न स्थिति कोड के लिए विशिष्ट क्रियाएँ लेने के लिए चाहते हैं, तो आप statusCode कॉलबैक का उपयोग कर सकते हैं:

1	$.ajax({ statusCode: { 404: function() { alert("page not found"); } } });

सारांश

तो यह है कि हमारे HTTP प्रोटोकॉल के त्वरित दौरे रकम ।

हम यूआरएल संरचना, क्रिया और स्थिति कोड की समीक्षा: HTTP संचार के तीन स्तंभों ।

अनुरोध और प्रतिक्रिया संदेश ज्यादातर समान हैं, पहली पंक्ति और संदेश शीर्ष लेखों को छोड़कर । अंत में, हम समीक्षा कैसे आप अनुरोध और वेब चौखटे और पुस्तकालयों में प्रतिक्रिया हेडर संशोधित कर सकते हैं ।

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

दो भाग में, हम कनेक्शन हैंडलिंग, प्रमाणीकरण और कैशिंग की समीक्षा करेंगे! तुम तो देखो ।