समय सीमा के साथ HTTP पुनः प्रयास को बाधित करें और अज्ञात परिणामों को संभालें

पूरे ऑपरेशन का बजट बनाएं

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

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

टाइमआउट तंत्र को समझें

ब्राउज़रों में, AbortSignal.timeout सक्रिय समय को मापता है। वह समय एक श्रमिक निलंबित होने या एक दस्तावेज़ बैक-फॉरवर्ड कैश में होने के दौरान रुक सकता है। इसे एक सार्वभौमिक दीवार-घड़ी समय सीमा के रूप में वर्णित न करें।

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

तय करें कि कौन से अनुरोध पुनः प्रयास किए जा सकते हैं

HTTP स्वतंत्रता एक समान अनुरोध को दोहराने के इच्छित प्रभाव का वर्णन करती है। GET जैसी सुरक्षित विधियां स्वतंत्र हैं, और PUT और DELETE भी अपनी परिभाषित शब्दावली द्वारा स्वतंत्र हैं। इसका अर्थ यह नहीं है कि हर दोहराव एक ही स्थिति लौटाता है या कि एक विशिष्ट सर्वर कार्यान्वयन सही है।

हर असफल प्रतिक्रिया को स्वचालित रूप से पुनः प्रयास न करें। एक स्थायी सत्यापन त्रुटि एक स्थायी सेवा विफलता के समान नीति में नहीं आनी चाहिए। POST और PATCH स्वतंत्र होने की गारंटी नहीं हैं, इसलिए एक अज्ञात परिणाम को API के विशिष्ट सुलझाने या डुप्लिकेशन-रोधी अनुबंध की आवश्यकता होती है।

नियोजन से पहले Retry-After की व्याख्या करें

Retry-After में सेकंडों की एक गैर-नकारात्मक संख्या या एक HTTP तिथि हो सकती है। सेकंड में एक विलंब प्रतिक्रिया प्राप्त करने के बाद मापा जाता है। HTTP तिथियों की वर्तमान समय के साथ तुलना की आवश्यकता होती है और वे घड़ी अंतरों से प्रभावित हो सकती हैं। एक लापता या विकृत मान एक असीमित या तत्काल पुनः प्रयास को अधिकृत नहीं करता।

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

HTTP/1.1 503 Service Unavailable
Retry-After: 120

एक सुसंगत समयरेखा का अनुसरण करें

मान लें कि एक काल्पनिक संचालन समय शून्य पर एक दस-सेकंड की समय सीमा के साथ शुरू होता है। प्रयास 1 विफल हो जाता है, और चुना गया बैकऑफ प्रयास 2 को तीन सेकंड के समय पर शुरू होने की अनुमति देता है। इस उदाहरण के लिए, मान लें कि इसका 503 प्रतिक्रिया उसी समय प्राप्त होती है जिसमें Retry-After: 120 है।

सात सेकंड शेष हैं, लेकिन अनुरोधित प्रतीक्षा 120 सेकंड है। अपेक्षित निर्णय यह है कि retry_after_exceeds_deadline जैसे कारण से रुका जाए। कोई तीसरा प्रयास नहीं होता। ये निर्णय को समझाने के लिए उपयोग की गई रचनात्मक मान हैं, नेटवर्क परीक्षण से प्राप्त माप नहीं।

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

बैकऑफ और प्रयास संख्या को सीमित करें

जब API पुनः प्रयास की अनुमति देता है और कोई उपयोगी Retry-After मान प्रदान नहीं करता है, तो एक सीमित बैकऑफ नीति प्रयासों को समय के साथ फैला सकती है। जिटर समय अवधियों को बदलकर समकालिक क्लाइंट्स को बार-बार एक साथ आने से रोकता है। कैप, यादृच्छिकीकरण और अधिकतम प्रयास संख्या को HTTP मानक द्वारा प्रदान की गई एक सार्वभौमिक एल्गोरिदम का दावा करने के बजाय अनुप्रयोग नीति के रूप में परिभाषित करें।

सोने से पहले, जांचें कि क्या चुनी गई प्रतीक्षा एक उपयोगी अगले प्रयास के लिए पर्याप्त समय छोड़ती है। जब यह नहीं करती है, तो रुकें। एक बड़ा Retry-After मान एक छोटे संचालन को छोड़ने का कारण है, न कि सर्वर की अनुरोधित प्रतीक्षा को सीमित करने और उसकी समाप्ति से पहले पुनः प्रयास करने का कारण।

एक अज्ञात लेखन परिणाम को सामंजस्य करें

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

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

प्रत्येक निर्णय का कारण रिकॉर्ड करें

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

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