HTTP 1xx और 102 Processing: आप प्रोटोकॉल बाउंड्री को कैसे समझाते हैं?

प्रॉम्प्ट और दायरा

एक इंटरव्यूअर पूछ सकता है: “HTTP 1xx अंतरिम प्रतिक्रियाओं और 102 Processing का क्या अर्थ है? यदि किसी लंबे अनुरोध के लिए प्रगति फ़ीडबैक की आवश्यकता है, तो आप इसे कैसे डिज़ाइन करेंगे?”

संकेत यह है कि क्या आप एक प्रोटोकॉल सिग्नल कि अनुरोध समाप्त नहीं हुआ है, एक अंतिम प्रतिक्रिया, और एक असिंक्रोनस ऑपरेशन रिसोर्स को अलग कर सकते हैं। RFC 9110 अंतिम गैर-1xx प्रतिक्रिया से पहले शून्य या अधिक 1xx अंतरिम प्रतिक्रियाओं की अनुमति देता है; यह 102 को एक सामान्य प्रतिशत-प्रगति प्रोटोकॉल में नहीं बदलता है। 102 की उत्पत्ति RFC 2518 में WebDAV स्थिति के रूप में हुई थी और इसे RFC 4918 द्वारा WebDAV से हटा दिया गया था। इसे प्रस्तावित करने से पहले प्रोटोकॉल संस्करणों, क्लाइंट्स और बिचौलियों (intermediaries) की जाँच करके शुरुआत करें।

इंटरव्यूअर क्या परीक्षण कर रहा है

क्या आप जानते हैं कि 1xx प्रतिक्रियाएँ अंतरिम हैं और अनुरोध को पूरा नहीं करती हैं।
क्या आप 100 Continue, 101 Switching Protocols और 102 Processing के बीच अंतर कर सकते हैं।
क्या आप सार्वभौमिक समर्थन का वादा करने के बजाय 102 के WebDAV इतिहास को पहचानते हैं।
क्या आप लंबे समय तक चलने वाले प्रोडक्ट प्रवाह के लिए 202 के साथ स्टेटस रिसोर्स, SSE या WebSocket चुन सकते हैं।
क्या आप प्रॉक्सी, टाइमआउट, पुनः प्रयास (retries), रद्दीकरण (cancellation), इडेम्पोटेंसी (idempotency), और परिणाम पुनर्प्राप्ति (result retrieval) का ध्यान रखते हैं।

स्पष्टीकरण के लिए प्रश्न

क्या अनुरोध को सिंक्रोनस ही रहना चाहिए, या कार्य बैकग्राउंड ऑपरेशन बन सकता है?
क्या रिवर्स प्रॉक्सी और गेटवे 1xx प्रतिक्रियाओं को अग्रेषित और प्रदर्शित करेंगे?
क्या उत्पाद को कीप-अलाइव संकेत की आवश्यकता है, या अवलोकनीय चरणों और प्रतिशत की?
क्या ऑपरेशन के ऐसे साइड इफेक्ट्स हैं जिन्हें पुनः प्रयास दोहरा सकता है?
क्या समाप्ति (expiry) और एक्सेस नियंत्रण के साथ एक अलग परिणाम संसाधन है?

30-सेकंड का उत्तर

आप कह सकते हैं:

1xx प्रतिक्रिया अंतरिम होती है; क्लाइंट को अभी भी एक अंतिम गैर-1xx प्रतिक्रिया की आवश्यकता होती है। 102 Processing एक WebDAV लंबे-ऑपरेशन परिदृश्य से आया था, इसलिए यह एक सामान्य प्रगति मॉडल नहीं है और यह नहीं माना जा सकता कि यह हर मध्यस्थ को पार करेगा। यदि कार्य असिंक्रोनस हो सकता है, तो मैं स्थिर स्थितियों, त्रुटियों, रद्दीकरण और एक परिणाम लिंक को प्रदर्शित करने वाले एक अधिकृत स्थिति संसाधन के साथ 202 वापस करूँगा। यदि कनेक्शन खुला रहना चाहिए, तो मैं क्लाइंट समर्थन के आधार पर SSE या किसी अन्य स्पष्ट इवेंट प्रोटोकॉल पर विचार करूँगा, और फिर वास्तविक प्रॉक्सी पथ का परीक्षण करूँगा।

चरण-दर-चरण तर्क

प्रतिक्रिया जीवनचक्र को परिभाषित करें

अंतरिम और अंतिम चरणों को अलग करें:

http

HTTP/1.1 102 Processing

HTTP/1.1 200 OK
Content-Type: application/json

{"result":"done"}

102 अनुरोध को समाप्त नहीं करता है या पूरा होने का वादा नहीं करता है। RFC 9110 का महत्वपूर्ण प्रतिबंध यह है कि एक अंतिम गैर-1xx प्रतिक्रिया अभी भी इसके बाद आती है; एक अंतरिम प्रतिक्रिया खो जाना अपने आप में किसी व्यावसायिक विफलता को साबित नहीं करता है।

102 के लिए सीमा निर्धारित करें

RFC 2518 ने 102 को एक लंबे ऑपरेशन के दौरान एक WebDAV संकेत के रूप में वर्णित किया, जिससे क्लाइंट को सक्रिय कनेक्शन को निष्क्रिय मानने से बचने में मदद मिली। यह मानकीकृत percentComplete, चरण मानों और त्रुटि सिमेंटिक्स वाला वर्कफ़्लो संसाधन नहीं है। RFC 4918 ने उस WebDAV परिभाषा को हटा दिया, इसलिए एक नए API को केवल संख्या पर निर्भर रहने के बजाय इसके लक्षित कार्यान्वयन और अनुकूलता का दस्तावेजीकरण करना चाहिए।

उत्पाद की आवश्यकता के लिए प्रोटोकॉल चुनें

जब पोलिंग स्वीकार्य हो, तो कार्रवाई को उसकी स्थिति से अलग करें: सबमिशन के लिए 202 और एक Location लौटाएं, फिर Pending, Running, Succeeded, Failed और Canceled जैसी स्थिर स्थितियों को प्रदर्शित करें। जब लाइव UI को चरण अपडेट की आवश्यकता हो तो SSE जोड़ें; WebSocket का मूल्यांकन केवल तभी करें जब द्विदिशात्मक नियंत्रण उचित हो। प्रत्येक विकल्प को पुनः कनेक्ट करने, बैकऑफ़, रद्दीकरण और प्राधिकरण के लिए एक योजना की आवश्यकता होती है।

डुप्लिकेट सबमिशन और अंतिम समापन को संभालें

निर्माण के लिए एक इडेम्पोटेंसी कुंजी स्वीकार करें और ऑपरेशन ID के साथ एक अनुरोध फ़िंगरप्रिंट बनाए रखें। उसी कुंजी के साथ पुनः प्रयास करने पर एक और साइड इफेक्ट को कतारबद्ध करने के बजाय वही ऑपरेशन वापस आता है। स्थिति पढ़ने को दोहराने योग्य बनाएं, टेनेंट जांच और समाप्ति के साथ परिणाम URL को सुरक्षित करें, और पुनः प्रयास सीमा के साथ संरचित त्रुटियों को प्रदर्शित करें। डिस्कनेक्ट, टाइमआउट या 102 प्रतिक्रिया कोई व्यावसायिक निष्कर्ष नहीं है।

मॉडल उच्च-गुणवत्ता वाला उत्तर

मैं पहले कीप-अलाइव संकेत को अवलोकनीय प्रगति से अलग करूँगा। यदि कोई सिंक्रोनस अनुरोध गेटवे टाइमआउट से अधिक हो सकता है, तो मैं सामान्य प्रगति API के रूप में 102 का उपयोग नहीं करूँगा: 1xx अंतरिम है, 102 का WebDAV इतिहास है, और मध्यवर्ती समर्थन असमान है। मेरा डिफ़ॉल्ट सबमिशन को मान्य करना, ऑपरेशन ID और स्थिति URL के साथ 202 लौटाना, और सीमित चरण जानकारी, अपडेट समय, संरचित त्रुटियों, रद्दीकरण और परिणाम URL को प्रदर्शित करना है। सबमिशन में एक इडेम्पोटेंसी कुंजी होती है ताकि पुनः प्रयास डुप्लिकेट कार्य न बनाएं। लाइव UI के लिए मैं अंतिम इवेंट ID या स्थिति संसाधन के माध्यम से पुनर्प्राप्ति के साथ SSE जोड़ सकता हूँ। सुरक्षा या अनुपालन जोखिम अभी भी औपचारिक वृद्धि और ऑडिट पथ का उपयोग करते हैं। यह प्रोटोकॉल सिग्नल, ऑपरेशन स्थिति और परिणाम संसाधनों को अलग रखता है।

सामान्य गलतियाँ

बिना किसी फ़ील्ड या क्लाइंट अनुबंध के 102 को प्रतिशत-प्रगति प्रतिक्रिया कहना।
किसी भी 1xx को सफलता या कनेक्शन बंद करने की अनुमति के रूप में मानना।
WebDAV से 102 के RFC 4918 निष्कासन को अनदेखा करना और सार्वभौमिक WebDAV समर्थन का दावा करना।
केवल मूल सर्वर पर चर्चा करना जबकि CDN, प्रॉक्सी, गेटवे और ब्राउज़र परीक्षणों को छोड़ देना।
स्थिति संसाधन, इडेम्पोटेंसी रणनीति, विफलता स्थिति या परिणाम प्राधिकरण के बिना 202 लौटाना।
डिस्कनेक्ट, टाइमआउट या पुनः प्रयासों को विफलता के प्रमाण के रूप में मानना और साइड इफेक्ट्स की नकल करना।

अनुवर्ती प्रश्न और उत्तर

1. 102 और 202 के बीच मुख्य अंतर क्या है?

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

2. क्या होगा यदि कोई प्रॉक्सी 1xx प्रतिक्रियाओं को अग्रेषित नहीं करता है?

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

3. आप अभी भी 102 का उपयोग कब करेंगे?

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