सामग्री बातचीत क्या है? HTTP प्रतिनिधित्व समझाया

सामग्री बातचीत क्या है?

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

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

API डेवलपर्स के लिए, पहला प्रश्न है कि मूल्य या व्यवहार कौन तैयार करता है। अगला प्रश्न है कि इसे कौन व्याख्या करता है। अंतिम प्रश्न है कि वे क्या अवलोकनीय परिणाम साबित करते हैं कि व्याख्या सफल रही। ये तीन उत्तर एक शब्दकोष की शर्त को एक परीक्षण योग्य इंटरफ़ेस अनुबंध में बदल देते हैं।

HTTP एक प्रतिनिधित्व का चयन कैसे करता है

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

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

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

जब उपलब्ध प्रतिनिधित्व स्वीकार्य नहीं होता है तो सर्वर 406 लौटाता है, हालाँकि कई सिस्टम एक डिफ़ॉल्ट चुनते हैं। अनुरोध बोडियों के लिए, 415 एक Unsupported media type की रिपोर्ट कर सकता है। प्रतिक्रिया प्राथमिकता और अनुरोध-बॉडी समर्थन संबंधित बातचीत हैं लेकिन विभिन्न दिशाओं में होती हैं।

प्रतिनिधित्व चयन के पीछे के क्षेत्र

निम्नलिखित शर्तें उन घटकों को अलग करती हैं जो अक्सर एक लेबल में समाहित होते हैं। इन्हें प्रतिभागियों के बीच इंटरफ़ेस के रूप में पढ़ें न कि नेटवर्क ट्रेस में सजावट के रूप में।

सामग्री बातचीत डेटा संग्रह में क्यों महत्वपूर्ण है

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

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

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

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

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

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

जहाँ वार्ता वास्तविक समस्या का समाधान करती है

सामग्री वार्ता आर्किटेक्चर में एक स्थान अर्जित करती है जब यह एक ठोस उत्पाद व्यवहार, संगतता आवश्यकताओं, या निदान निर्णय को बदलती है। ये उपयोग के मामले पहले कार्य को और फिर प्रोटोकॉल फीचर का वर्णन करते हैं।

प्रोएक्टिव, रिएक्टिव, और URL-आधारित चयन

सामग्री वार्ता HTTP की एक परत से संबंधित है और इसे समांतर परतों के साथ भ्रमित नहीं होना चाहिए। एक उचित कार्यान्वयन पहचानता है कि कौन सा घटक मूल्य का चयन करता है, कौन सा घटक इसे बदल सकता है, और क्या प्रमाण है कि अंतिम प्रतिनिधित्व सही है।

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

सामग्री वार्ता की गलतियाँ

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

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

एक प्रस्तुति चयन ऑडिट

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

1. एक संसाधन के लिए वास्तव में उपलब्ध प्रस्तुतियों और भिन्नता वाले आयामों की सूची बनाएं।
2. एक समय में नियंत्रित स्वीकार, स्वीकार-भाषा, और स्वीकार-एन्कोडिंग मान भेजें।
3. प्रत्येक परिणाम के लिए सामग्री-प्रकार, सामग्री-भाषा, सामग्री-एन्कोडिंग, और भिन्नताओं को रिकॉर्ड करें।
4. एक अस्वीकृत प्राथमिकता का परीक्षण करें और यह दस्तावेज करें कि क्या सर्वर 406 या एक डिफॉल्ट लौटाता है।
5. भिन्न प्राथमिकताओं का प्रदर्शन करने वाले दो क्लाइंट के साथ साझा कैश की जाँच करें।
6. जांचें कि पुनर्निर्देशित करने से इरादित वेरिएेंट अनुबंध को बनाए रखा जाता है और भाषा या प्रारूप चयन को मिटाया नहीं जाता है।
7. जिसके लिए पाठक या सिस्टम बुकमार्क, अनुक्रमण, या सीधे तुलना करने की आवश्यकता है, उसके लिए एक विशिष्ट URL रखें।

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

सामग्री वार्ता के लिए सुरक्षा और अवलोकनशीलता

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

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

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

सामग्री वार्ता को परिभाषित करने वाले मानक

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

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

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

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

निगोशिएशन डिज़ाइन परीक्षण

कई प्रस्तुतियों को वास्तविक रूप से एक संसाधन पहचान साझा करते समय सामग्री वार्ता का उपयोग करें, चयन आयामों को स्पष्ट रखें, और कैश भिन्नता और प्रतिक्रिया मेटाडेटा को अनुबंध का हिस्सा बनाएं।

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

संदर्भ

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