मैंने पहले ही इस विषय पर बहुत कुछ जाना है, इस हेडर के बारे में विभिन्न लेख, हेरोकू में इसके उपयोग और Django पर आधारित परियोजनाओं के बारे में पढ़ा।
हालाँकि, यह अभी भी मेरे सिर में उलझा हुआ है।
जवाबों:
जब आप ग्राहकों द्वारा एक्सेस की जा रही एक webservice का संचालन कर रहे हैं, तो सर्वर लॉग के साथ अनुरोधों (जिसे एक ग्राहक देख सकता है) (जो सर्वर देख सकता है) को सहसंबंधित करना मुश्किल हो सकता है।
इसका विचार यह X-Request-IDहै कि एक क्लाइंट कुछ रैंडम आईडी बना सकता है और इसे सर्वर को पास कर सकता है। सर्वर तब उस आईडी को हर लॉग स्टेटमेंट में शामिल करता है जिसे वह बनाता है। यदि क्लाइंट को कोई त्रुटि मिलती है, तो यह बग रिपोर्ट में आईडी को शामिल कर सकता है, जिससे सर्वर ऑपरेटर को संबंधित लॉग स्टेटमेंट (टाइमस्टैम्प, आईपी आदि पर भरोसा किए बिना) देखने की अनुमति मिलती है।
चूंकि यह आईडी क्लाइंट द्वारा (बेतरतीब ढंग से) उत्पन्न की जाती है, इसमें कोई संवेदनशील जानकारी नहीं होती है, और इस प्रकार इसे उपयोगकर्ता की गोपनीयता का उल्लंघन नहीं करना चाहिए। जैसा कि एक अद्वितीय आईडी प्रति अनुरोध बनाया गया है, यह ट्रैकिंग उपयोगकर्ताओं के साथ भी मदद नहीं करता है।
उद्देश्य: आदर्श
एक आईडी के साथ जो हर अनुरोध के लिए बदल जाती है, लेकिन अनुरोध की पुनर्प्राप्ति के मामले में समान रहती है, रिसीवर यह सुनिश्चित कर सकता है कि अनुरोध एक से अधिक बार संसाधित नहीं होगा।
यह कुछ एपीआई प्रदाता का एक उद्धरण है:
सभी POST, PUT, और PATCH HTTP अनुरोधों में एक अद्वितीय X-Request-Id हेडर होना चाहिए जो एक रिट्री के मामले में सुखद संदेश प्रसंस्करण सुनिश्चित करने के लिए उपयोग किया जाता है
यदि आप इसे एक यादृच्छिक स्ट्रिंग बनाते हैं , तो प्रति अनुरोध अद्वितीय , यह आपकी गोपनीयता का उल्लंघन नहीं करेगा, और न ही ट्रैकिंग को सक्षम करेगा।
यदि आप और अधिक जानना चाहते हैं कि क्या बेवकूफी पेश करनी है, तो इस व्यावहारिक लेख को पढ़ें ।
NB As Stefan Kögl टिप्पणी, यह शीर्ष लेख मानकीकृत नहीं है - इसलिए (पदावनत) "X-" उपसर्ग।
आपका इंटरनेट चल रहा है (हमेशा की तरह), इसलिए आप टेल्स्ट्रा को फोन करते हैं और आप हमेशा के लिए फोन पर प्रतीक्षा कर रहे हैं ...... अंत में आप हार मान लेते हैं और निराशा में फोन को नीचे गिरा देते हैं। (यह एक विफल कॉल है। और टेल्स्ट्रा की कॉल लॉग्स में इसका रिकॉर्ड है।)
"यह बात है, मैं लोकपाल को बुला रहा हूं!"
लेकिन ओम्बुड्समैन के पास हजारों कॉल रिकॉर्ड हैं, जिससे गुजरने के लिए (टेल्स्ट्रा के सभी असफल प्रश्नों)। यदि आप उन्हें बताते हैं कि आपने टेल्स्ट्रा को कॉल किया, और आपकी कॉल असफल रही, तो यह पर्याप्त नहीं होगा: ओम्बड्समैन को कैसे पता चलेगा कि टेलस्ट्रा के सभी कॉल रिकॉर्ड से, कौन सा आपका था - ताकि इसकी आगे जांच की जा सके? ?
यहीं पर X-Request-ID आती है - जब आप कभी भी Saystra को कॉल करते हैं, तो आप एक यादृच्छिक संख्या (X-Request-ID) पर पास होते हैं और यह Tellstra रिकॉर्ड में लॉग होता है। इस तरह, लोकपाल (सभी रिकॉर्ड तक पहुंच) आपके आने वाले कॉल को यह पता लगाने में सक्षम होगा कि क्या गलत हुआ।
Http अनुरोधों पर भी यही बात लागू होती है - यह एक आईडी है जिसका उपयोग आपकी मदद करने के लिए किया जाता है (जैसा कि बैक एंड देव) यह पता करें कि जब कोई ग्राहक आपको त्रुटि या बड़ी रिपोर्ट जारी करता है तो क्या गलत हुआ।
वह इसका मूल सारांश है। कोई प्रश्न आदि केवल एक टिप्पणी पोस्ट करते हैं और मैं इसे स्पष्ट करने की उम्मीद करता हूं।
इस अनुरोध शीर्षलेख का उपयोग सिंक्रोनाइज़ेशन के लिए किया जा सकता है। मान लीजिए कि आपने एक ToDo सूची बनाई है जो ऑफ़लाइन क्षमता प्रदान करती है। आपका उपयोगकर्ता 3 आइटम बनाता है और उनमें से प्रत्येक को ऑफ़लाइन एप्लिकेशन पर एक अद्वितीय यूयूआईडी दिया जाता है। जब नेटवर्क कनेक्टिविटी उपलब्ध होती है, तो रिकॉर्ड सर्वर पर पोस्ट कर दिए जाते हैं और डेटाबेस से ऑटो-जेनरेट किए गए संबंधित आईडी को लौटा दिया जाता है। फिर आप अपने ऐप में आईडी को बदल सकते हैं (उदाहरण के लिए "आईडी" एचटीएमएल "ली" तत्व की विशेषता)।