HTTP क्या है? तरीके, संदेश, स्थिति कोड, और कैशिंग
Scrapeless Universal Scraping API HTTP रिक्वेस्ट स्वीकार करता है और सार्वजनिक डेटा निकालने के वर्कफ़्लो के लिए वेब सामग्री लौटाता है।
TL;DR
- HTTP एक अनुरोध-प्रतिक्रिया प्रोटोकॉल है। एक क्लाइंट एक अनुरोध भेजता है और एक सर्वर एक प्रतिक्रिया लौटाता है।
- संसाधनों की पहचान URI द्वारा की जाती है। प्रतिक्रिया संसाधन का प्रतिनिधित्व ले जाती है, स्वयं संसाधन नहीं।
- तरीके इरादे को व्यक्त करते हैं। GET, POST, PUT, DELETE, और अन्य तरीकों का परिभाषित अर्थ होता है।
- स्थिति कोड परिणामों को वर्गीकृत करते हैं। पहला अंक सूचना, सफल, मार्गनिर्देशन, क्लाइंट-त्रुटि, और सर्वर-त्रुटि प्रतिक्रियाओं को समूहित करता है।
- HTTP का अर्थ प्रत्येक तार संस्करण से परे रहता है। फ्रेमिंग संस्करणों के बीच बदलता है जबकि तरीके और प्रतिक्रिया का अर्थ परिचित रहते हैं।
परिचय
HTTP अनुप्रयोग-स्तर का प्रोटोकॉल है जो वेब को संसाधनों की पहचान और प्रतिनिधित्वों का आदान-प्रदान करने के लिए एक साझा शब्दावली देता है। एक ब्राउज़र एक दस्तावेज़ का अनुरोध कर सकता है, एक API क्लाइंट JSON प्रस्तुत कर सकता है, और एक क्रॉलर HTML को पुनः प्राप्त कर सकता है क्योंकि प्रत्येक पक्ष एक समान तरीके, फ़ील्ड, स्थिति कोड, और संदेश अर्थ को समझता है।
HTTP एक निश्चित अनुप्रयोग डेटा मॉडल को परिभाषित नहीं करता। यह परिभाषित करता है कि एक अनुरोध एक इरादा कैसे बताता है और एक प्रतिक्रिया परिणाम का विवरण कैसे देती है। समान अर्थ HTTP/1.1, HTTP/2, और HTTP/3 में जीवित रहते हैं, भले ही वे संस्करण संदेशों को अलग-अलग एन्कोड और परिवहन करते हैं।
संसाधन, प्रतिनिधित्व, और URI
HTTP उन संसाधनों पर संचालित होता है जिनकी पहचान URI द्वारा की जाती है। एक उत्पाद रिकॉर्ड, एक छवि, एक खोज परिणाम, और एक नौकरी की स्थिति प्रत्येक एक संसाधन हो सकती है। लौटाए गए बाइट्स उस अनुरोध के लिए चुना गया प्रतिनिधित्व हैं, शायद HTML, JSON, एक छवि, या अनुरोधित भाषा में संकुचित सामग्री।
अभेद्यता महत्वपूर्ण है क्योंकि एक URI के लिए कई प्रतिनिधित्व हो सकते हैं। अनुरोध फ़ील्ड जैसे कि Accept और Accept-Language क्लाइंट की प्राथमिकताओं का वर्णन करते हैं, जबकि प्रतिक्रिया फ़ील्ड जैसे कि Content-Type और Content-Encoding बताते हैं कि क्या भेजा गया था। RFC 9110 HTTP अर्थों को परिभाषित करता है वर्तमान संस्करणों द्वारा साझा किया गया।
एक अनुरोध की संरचना
एक अनुरोध में एक तरीका, लक्ष्य, फ़ील्ड, और कभी-कभी सामग्री होती है। GET एक प्रतिनिधित्व के लिए पूछता है। HEAD उत्तर सामग्री के बिना वही मेटाडाटा पूछता है। POST प्रसंस्करण के लिए जानकारी प्रदान करता है। PUT एक लक्ष्य संसाधन का प्रतिस्थापन करने के लिए अनुरोध करता है, जबकि DELETE सर्वर से एक संबंध को हटाने के लिए कहता है।
विधि नाम केवल रूटिंग लेबल नहीं हैं। सुरक्षा और आइडेम्पोटेंसी कैशिंग, स्वचालित उपकरणों, और अनिश्चित नेटवर्क परिणामों के बाद क्लाइंट को पुनः प्राप्त करने के तरीके को प्रभावित करते हैं। एक सर्वर अनुप्रयोग-विशिष्ट व्यवहार को उजागर कर सकता है, लेकिन इसे स्वीकार किए गए तरीके के मानकीकरण अर्थ को बनाए रखना चाहिए।
एक प्रतिक्रिया की संरचना
एक प्रतिक्रिया में एक स्थिति कोड, फ़ील्ड, और वैकल्पिक सामग्री होती है। एक 2xx कोड सफल हैंडलिंग की रिपोर्ट करता है, 3xx क्लाइंट को कहीं और या कैश की स्थिति की ओर निर्देशित करता है, 4xx अनुरोध में एक समस्या को रिपोर्ट करता है, और 5xx रिपोर्ट करता है कि सर्वर एक मान्य अनुरोध को पूरा नहीं कर सका।
हेडर चयनित प्रतिनिधित्व, प्रमाणीकरण चुनौती, कैश नीति, मान्यता, रेंज, कुकीज़, और मध्यवर्तियों के बारे में मेटाडाटा ले जाते हैं। प्रतिक्रिया शरीर की गारंटी नहीं है: HEAD, 204, और 304 प्रतिक्रियाओं के विशेष सामग्री नियम होते हैं, और त्रुटि प्रतिक्रियाएँ एक अनुप्रयोग-परिभाषित प्रारूप में उपयोगी विश्लेषण प्रदान कर सकती हैं।
Stateless का मतलब मेमोरीलेस एप्लिकेशन नहीं होता
HTTP अस्थायी है क्योंकि प्रत्येक अनुरोध को पिछले अनुरोध से प्रोटोकॉल-स्तरीय वार्तालाप स्थिति के बिना समझा जा सकता है। एप्लीकेशन फिर भी कुकीज़, प्रमाणीकरण क्रेडेंशियल, सर्वर-साइड सत्र, डेटाबेस रिकॉर्ड, और टोकनों के माध्यम से स्थिति बनाए रखती है।
यह विभाजन प्रोटोकॉल को सामान्य बनाए रखता है। एक शॉपिंग कार्ट तब तक बनी रह सकती है जब तक प्रत्येक HTTP अनुरोध आत्म-व्याख्यात्मक होता है ताकि मार्ग और प्रसंस्करण किया जा सके। डिजाइनरों को अनुप्रयोग स्थिति को कनेक्शन स्थिति से अलग करना चाहिए और यह मानने से बचना चाहिए कि वही नेटवर्क कनेक्शन समान प्रमाणीकृत उपयोगकर्ता को बताता है।
कैशिंग और शर्तीय अनुरोध
कैश एक संरक्षित प्रतिक्रिया का पुन: उपयोग कर सकते हैं जब विधि, स्थिति, ताजगी, और कैश-नियंत्रण नियम इसकी अनुमति देते हैं। ताजगी मूल से संपर्क करने से बचती है। मान्यता एक कैश को यह पूछने देती है कि क्या एक संग्रहीत प्रतिनिधित्व अभी भी वर्तमान है या नहीं, एक शर्तीय अनुरोध में एक एंटिटी टैग या संशोधन तिथि भेजकर।
एक सफल मान्यता 304 को बिना प्रतिनिधित्व को फिर से स्थानांतरित किए लौटाई जा सकती है। सही कैश कुंजियाँ लक्ष्य URI और चयनित अनुरोध फ़ील्ड का ध्यान रखनी चाहिए जिनका नाम Vary है। HTTP कैशिंग विनिर्देशन इन नियंत्रणों की परिभाषा करता है और जब निर्देश सही ढंग से सेट होते हैं तो उपयोगकर्ताओं के बीच एक निजी प्रतिक्रिया लीक होने से रोकता है।
कनेक्शन, प्रॉक्सी, और संस्करण
HTTP संदेश प्रॉक्सियों, गेटवे, कैश, और सामग्री वितरण नेटवर्क के माध्यम से उत्पत्ति तक पहुँचने से पहले पारित हो सकते हैं। प्रत्येक मध्यवर्ती प्रोटोकॉल के नियमों के भीतर संदेशों को मार्ग, प्रमाणीकरण, रूपांतरित, या संग्रहीत कर सकता है। अंत से अंत के फ़ील्ड संसाधन आदान-प्रदान का वर्णन करते हैं; कनेक्शन-विशिष्ट हैंडलिंग प्रोटोकॉल संस्करण पर निर्भर करती है।
HTTP/1.1 बाइट स्ट्रीम पर पाठ्य संदेश स्वरूप का उपयोग करता है। HTTP/2 समान अर्थों को बाइनरी फ़्रेम और मल्टीप्लेक्स स्ट्रीम में मानचित्रित करता है। HTTP/3 उन्हें QUIC पर मानचित्रित करता है। MDN का HTTP अवलोकन समान क्लाइंट, सर्वर, और मध्यवर्ती मॉडल का ब्राउज़र-उन्मुख दृश्य प्रदान करता है।
| भाग | उद्देश्य | उदाहरण |
|---|---|---|
| तरीका | अनुरोध इरादा बताता है | GET |
| लक्ष्य | संसाधन की पहचान करता है | /products/42 |
| अनुरोध फ़ील्ड | पसंदीगियों या संदर्भ जोड़ता है | स्वीकृत: application/json |
| स्थिति कोड | परिणाम को वर्गीकृत करता है | 200 ठीक है |
| प्रतिक्रिया फ़ील्ड | सामग्री या नीति का वर्णन करता है | सामग्री-प्रकार: application/json |
| सामग्री | प्रस्तुति डेटा ले जाता है | JSON, HTML, छवि बाइट्स |
HTTP क्या है? तरीके, संदेश, स्थिति कोड और कैशिंग सत्यापन योजना
HTTP एक अनुरोध-प्रतिक्रिया प्रोटोकॉल है। एक क्लाइंट एक अनुरोध भेजता है और एक सर्वर एक प्रतिक्रिया लौटाता है। उस दावे को पूरे उत्पादन पथ के साथ मान्य करें। एक छोटे प्रतिनिधि विनिमय के साथ शुरू करें, क्लाइंट और एज पर बातचीत व्यवहार को रिकॉर्ड करें, और पुष्टि करें कि आवेदन को वही क्षेत्रों, फ़्रेम, या घटनाएँ प्राप्त होती हैं जिनकी वह उसी गेटवे, प्रॉक्सी, प्रमाण पत्र समाप्ति बिंदु, और नेटवर्क नीति के माध्यम से अपेक्षा करता है जिसका उपयोग वास्तविक ट्रैफ़िक द्वारा किया जाता है।
पहले डिज़ाइन धारणा को असफलता अभ्यास में बदलें: स्थिर URI के साथ संसाधनों का नामकरण करें। फिर दूसरे धारणा के चारों ओर संसाधन दबाव की जांच करें: उनके परिभाषित अर्थ के लिए विधियों का चयन करें। एक सही कार्यान्वयन को प्रलेखित सीमाओं के भीतर असफल होना चाहिए, कनेक्शन और बफ़र स्थिति छोड़ना चाहिए, और एक ऐसा निशान छोड़ना चाहिए जो परिणाम को समझाने के लिए बिना क्रेडेंशियल या निजी पेलोड्स को उजागर किए।
वेब नेविगेशन और मशीन एपीआई डिज़ाइन के विभिन्न भागों का अभ्यास करते हैं, इसलिए संगतता परीक्षण में संबंधित ट्रैफ़िक आकृतियों को शामिल करना चाहिए। एक वर्तमान ब्राउज़र, गैर-ब्राउज़र क्लाइंट, धीमी नेटवर्क पथ, और सबसे पुराने समर्थित अंतराल को जोड़ें। पसंदीदा पथ और इसके बैकअप के लिए संस्करण चयन, कनेक्शन जीवनकाल, संदेश या प्रतिक्रिया आयु, कतार की गहराई, और समापन कारण को रिकॉर्ड करें।
परिक्षण के दौरान प्रोटोकॉल और परिवहन को अलग-अलग परतों के रूप में समीक्षा करें। एक सफल कनेक्शन यह प्रमाणित नहीं करता है कि अनुप्रयोग ने आदेश, प्राधिकरण, रद्दीकरण, कैशिंग, पुनः खेल, या स्थिति पुनर्प्राप्ति को सही ढंग से संभाला है। इसी तरह, एक अनुप्रयोग त्रुटि यह प्रमाणित नहीं करती है कि बातचीत का प्रोटोकॉल असफल हुआ। अवलोकनों को संसाधन, उपयोगकर्ता क्षेत्र, तार्किक कार्य और कनेक्शन पहचानकर्ता के साथ टैग करें, फिर तुलना करें कि प्रत्येक अंत बिंदु ने क्या किया। यह पृथक्करण क्षमता के कार्य को अधिक उपयोगी बनाता है: टीमें देख सकती हैं कि क्या विलंब कनेक्शन सेटअप, नेटवर्क वितरण, कतार, अनुप्रयोग प्रोसेसिंग, अनुक्रमण या धीमे रिसीवर से आया। नियमित टेलीमेट्री से निजी सामग्री को बाहर रखें जबकि निर्णय को पुन: उत्पन्न करने के लिए पर्याप्त समय और परिणाम डेटा बनाए रखें।
जहाँ HTTP क्या है? तरीके, संदेश, स्थिति कोड और कैशिंग प्रायोगिक रूप में प्रकट होता है
वेब नेविगेशन
ब्राउज़र HTTP के माध्यम से दस्तावेज़, शैलियाँ, स्क्रिप्ट, छवियाँ और एपीआई डेटा लाते हैं।
मशीन एपीआई
सेवाएँ स्पष्ट विधियों और स्थिति कोडों का उपयोग करके JSON या अन्य प्रस्तुतियों का आदान-प्रदान करती हैं।
वेब डेटा संग्रहण
क्लाइंट सार्वजनिक पृष्ठों का अनुरोध करते हैं और सामग्री को पार्स करने से पहले प्रतिक्रिया मेटाडेटा का निरीक्षण करते हैं।
सामग्री वितरण
कैश और मध्यवर्ती प्रस्तुतियों का पुनः उपयोग करते हैं और अनुरोधों को उपयोगकर्ताओं के निकट मार्गित करते हैं।
HTTP क्या है? तरीके, संदेश, स्थिति कोड और कैशिंग उत्पादन चेकलिस्ट
- स्थिर URI के साथ संसाधनों का नामकरण करें। इस बिंदु को एक लिखित स्वीकृति परीक्षण में परिवर्तित करें ताकि समीक्षक इरादे वाले व्यवहार को एक आकस्मिक कार्यान्वयन विवरण से भिन्न कर सकें।
- उनके परिभाषित अर्थ के लिए विधियों का चयन करें। उस घटक का नाम बताएं जो सेटिंग का मालिक है और वह व्यक्ति या टीम जो तब प्रतिक्रिया करती है जब इसके अवलोकित व्यवहार में परिवर्तन होता है।
- वास्तविक परिणाम का वर्णन करने वाले स्थिति कोड लौटाएँ। लॉग्स या ट्रेस में प्रासंगिक सिग्नल कैप्चर करें, फिर सत्यापित करें कि सिग्नल वास्तविक पथ में प्रत्येक प्रॉक्सी, गेटवे और सेवा सीमा के पार जीवित रहता है।
- हर प्रस्तुति के लिए सामग्री-प्रकार सेट करें। सामान्य मामले, धीमे साथी, बंद कनेक्शन, बड़े इनपुट, और संस्करण या क्षमता असंगति के साथ निर्णय का परीक्षण करें।
- सहमति की स्थिति को कनेक्शन पहचान से अलग करें। सुरक्षित डिफ़ॉल्ट और उस सटीक स्थिति का दस्तावेज़ीकरण करें जो एक अपवाद की अनुमति देता है; छिपे हुए अपवाद बाद के परिवर्तनों के दौरान अंतःक्रियाशीलता की समस्याएं बनते हैं।
- संवेदनशील प्रतिक्रियाओं के लिए कैश व्यवहार को स्पष्ट रूप से परिभाषित करें। इस व्यवहार की जांच एक प्रतिनिधि ब्राउज़र या क्लाइंट से करें न कि केवल एक स्थानीय इकाई परीक्षण या सर्वर-पक्ष की कॉन्फ़िगरेशन स्क्रीन पर निर्भर रहें।
- बड़े या बार-बार जांचे जाने वाले संसाधनों के लिए मान्यता जाँचकर्ताओं का उपयोग करें। एक सीमित संसाधन सीमा निर्धारित करें और परिणामस्वरूप अस्वीकृति को ऑपरेटरों और कॉल करने वाले अनुप्रयोग के लिए दृश्य बनाएं।
- मध्यस्थों के बीच अनुरोध पहचानकर्ताओं को लॉग करें। एक तार्किक विनिमय को क्लाइंट, एज, अनुप्रयोग, और किसी भी असिंक्रोनस कार्यकर्ता के बीच सहसंबंधित करने के लिए पर्याप्त पहचानकर्ताओं को बनाए रखें।
- संगत प्रारूप में क्लाइंट-दृश्य त्रुटियों को बनाए रखें। एक ट्रैफ़िक-आकृति परिवर्तन के बाद चयन की समीक्षा करें क्योंकि कनेक्शन की संख्या, पेलोड का आकार, और संदेश की आवृत्ति सही डिज़ाइन को बदल सकती है।
- आपके एज द्वारा समर्थित प्रोटोकॉल संस्करणों के पार व्यवहार का परीक्षण करें। फॉलबैक पथ को प्रेक्षणीय और परीक्षण किया हुआ रखें ताकि संगतता एक पुराने पथ पर निर्भर न करे जो चुपचाप काम करना बंद कर देता है।
निष्कर्ष
HTTP एक अनुरोध-प्रतिसाद प्रोटोकॉल है। एक ग्राहक एक अनुरोध भेजता है और एक सर्वर एक प्रतिक्रिया वापस करता है। HTTP अर्थ प्रत्येक वायर संस्करण से परे रहता है। फ्रेमिंग संस्करणों के बीच बदलती है जबकि विधियाँ और प्रतिक्रिया का अर्थ परिचित रहता है। उन दो तथ्यों का उपयोग करें जिनमें स्पष्ट सीमाएँ, प्रेक्षणीय स्थिति और एक फॉलबैक है जो प्रतिनिधि ग्राहकों द्वारा परीक्षण किया गया है न कि कॉन्फ़िगरेशन से अनुमानित।
क्या आप एक विश्वसनीय वेब डेटा कार्यप्रवाह बनाने के लिए तैयार हैं?
Scrapeless के साथ प्रोटोकॉल निर्णयों को प्रेक्षणीय ब्राउज़र और एपीआई कार्यप्रवाहों में बदलें।
आज ही साइन अप करें और प्राप्त करें $5 निःशुल्क क्रेडिट — कोई क्रेडिट कार्ड की आवश्यकता नहीं.
अपना $5 क्रेडिट प्राप्त करें →अक्सर पूछे जाने वाले प्रश्न
क्या HTTP एन्क्रिप्टेड है?
HTTP अपने आप में एन्क्रिप्शन की आवश्यकता नहीं है। https URI स्कीम HTTP को एक प्रमाणित TLS कनेक्शन के माध्यम से डेटा को स्थानांतरित करने के लिए उपयोग करती है।
क्या HTTP स्टेटलेस है?
हां, HTTP अर्थ स्टेटलेस हैं, लेकिन अनुप्रयोग कुकीज़, टोकन, डेटाबेस और अन्य तंत्र के साथ उपयोगकर्ता और कार्यप्रवाह की स्थिति बनाए रख सकते हैं।
एक संसाधन और एक प्रतिनिधित्व के बीच क्या अंतर है?
एक संसाधन वह वैकल्पिक लक्ष्य है जिसे एक URI द्वारा पहचाना जाता है; एक प्रतिनिधित्व वह वर्तमान डेटा है जो उस संसाधन के लिए चयनित प्रारूप में भेजा जाता है।
क्या HTTP/2 और HTTP/3 अलग एपीआई हैं?
आमतौर पर नहीं। अनुप्रयोग एक समान विधियाँ, स्थिति कोड और क्षेत्रों को बनाए रखते हैं जबकि ग्राहक और सर्वर एक अलग परिवहन मानचित्रण पर बातचीत करते हैं।
क्या HTTP डेटा स्ट्रीम कर सकता है?
हां। एक HTTP प्रतिक्रिया खुली रह सकती है और समय के साथ सामग्री प्रदान कर सकती है, जो सर्वर-सेंट इवेंट्स जैसे पैटर्न का आधार है।