किसी विफल अनुरोध के लिए प्रतीक्षा, किसी फ़ील्ड में सुधार या दूसरे क्रेडेंशियल की ज़रूरत हो सकती है। Bird की त्रुटि प्रतिक्रिया ऐसे फ़ील्ड देती है जिनसे आपका हैंडलर सही कार्रवाई चुन सकता है।
मुझे कौन-से त्रुटि फ़ील्ड इस्तेमाल करने चाहिए?
सामान्य हैंडलिंग के लिए type और किसी विशिष्ट रिकवरी के लिए code का उपयोग करें। Bird ये फ़ील्ड शीर्ष-स्तरीय error ऑब्जेक्ट के अंदर रखता है।
प्रकार विफलताओं को समूहों में बाँटता है, जैसे वैलिडेशन, ऑथेंटिकेशन और अनुरोध दर सीमित करना। कोड किसी खास विफलता की पहचान करता है, जैसे फ़ील्ड वैलिडेशन के लिए E01001।
Bird किसी कोड का नाम कभी नहीं बदलता और उसे दोबारा उपयोग नहीं करता। हटाए गए कोड आरक्षित रहते हैं, इसलिए किसी मौजूदा कोड से किया गया मिलान अपना अर्थ बनाए रखता है।
message को दिखाएँ या लॉग करें, लेकिन उसके टेक्स्ट से मिलान न करें। शब्द बदल सकते हैं, जबकि आपके हैंडलर को जिस विफलता से निपटना है वह वही रहती है।
name लॉग को पढ़ने योग्य बनाता है। doc_url उस कोड के दस्तावेज़ से लिंक करता है। कोई ऑपरेशन विफल होने पर code, name और request_id को एक साथ लॉग करें।
किन विफलताओं के लिए फिर से प्रयास करना चाहिए?
अस्थायी विफलताओं के लिए सीमित नीति के साथ फिर से प्रयास करें। दोबारा कोशिश करने से पहले इनपुट और क्रेडेंशियल की समस्याएँ ठीक करें। जब एक ही स्टेटस के लिए अलग-अलग कार्रवाई की ज़रूरत हो सकती है, तो विशिष्ट कोड जाँचें।
| प्रतिक्रिया | डिफ़ॉल्ट कार्रवाई |
|---|---|
429, E01003 | Retry-After तक प्रतीक्षा करें, फिर से प्रयास करें। |
500, 502, 503 या 504 | रीड अनुरोधों पर सीमित बैकऑफ़ के साथ फिर से प्रयास करें; राइट अनुरोध अपने आइडेम्पोटेंसी अनुबंध का पालन करते हैं। |
501 | रुकें और जाँचें कि सर्वर कौन-सा ऑपरेशन सपोर्ट करता है। |
401 या 403 | फिर से प्रयास करने से पहले क्रेडेंशियल या उसकी अनुमतियाँ ठीक करें। |
| फ़ील्ड वैलिडेशन या अमान्य इनपुट | प्रतिक्रिया में बताए गए फ़ील्ड ठीक करें। |
409, E01004 | फिर से प्रयास करने से पहले चल रहे ऑपरेशन के पूरा होने की प्रतीक्षा करें। |
409, E01005 | एक ही आइडेम्पोटेंसी कुंजी को अलग इनपुट के साथ दोबारा उपयोग करने की गलती ठीक करें। |
आइडेम्पोटेंसी गारंटी यह सुनिश्चित करती है कि तीन घंटे के भीतर मेल खाने वाले फिर से प्रयास ठीक एक बार स्वीकार हों। किसी राइट अनुरोध पर वही कुंजी और बिल्कुल वही अनुरोध भेजकर, सीमित बैकऑफ़ के साथ फिर से प्रयास करें। टाइमआउट या सर्वर विफलता के बाद यह पता नहीं होता कि अनुरोध स्वीकार हुआ या नहीं। कुंजी बदलने से एक अलग ऑपरेशन बन जाता है। फिर से प्रयास खत्म होने या रिटेंशन अवधि बीत जाने के बाद, मिलान होने तक उस परिणाम को अनिर्णीत मानें।
फिर से प्रयास का बजट खत्म होने पर रुकें और अंतिम त्रुटि दर्ज करें। बिना बदलाव वाले अनुरोध को अनिश्चित काल तक दोहराने से ऐसी विफलता छिप सकती है जिसमें हस्तक्षेप की ज़रूरत है।
फ़ील्ड वैलिडेशन त्रुटियों को कैसे संभालें?
E01001 ValidationError पर मौजूद details ऐरे पढ़ें और हर एंट्री को उसके param से जोड़ें। उस एंट्री का message प्रभावित फ़ील्ड के पास दिखाएँ।
फ़ील्ड या विफलता पहचानने के लिए उन संदेशों को पार्स न करें। शीर्ष-स्तरीय संदेश की तरह उनके शब्द भी बदल सकते हैं।
गलत ढंग से बना अनुरोध इसके बजाय E01002 InvalidRequest लौटा सकता है। यह मानने के बजाय कि हर इनपुट विफलता में फ़ील्ड-स्तर का विवरण होता है, उसके लिए दर्ज रिकवरी तरीका अपनाएँ।
क्या प्रतिक्रिया बता सकती है कि रिकवरी कैसे करें?
कुछ त्रुटियों में remediation होता है, यानी पढ़ने योग्य अगला कदम, या next, यानी आज़माने के लिए ऑपरेशनों की क्रमबद्ध सूची।
जब समाधान से व्यक्ति को समस्या ठीक करने में मदद मिले, तो उसे दिखाएँ। उदाहरण के लिए, अधिकार संबंधी विफलता में अतिरिक्त स्कोप वाले क्रेडेंशियल की ज़रूरत हो सकती है।
स्वचालित हैंडलर रिकवरी ऑपरेशन चुनने के लिए next का उपयोग कर सकता है। फिर भी उसे चलाने से पहले उस ऑपरेशन के इनपुट और अनुमतियाँ चाहिए।
vendor_code किसी डाउनस्ट्रीम विफलता की पहचान करता है, जैसे SMTP प्रतिक्रिया या भुगतान अस्वीकृति। जब रिकवरी उस पर निर्भर हो, तो उस प्रदाता का कोड देखें।
अपरिचित कोड मिलने पर क्या होना चाहिए?
एक डिफ़ॉल्ट ब्रांच रखें जो क्रैश हुए बिना या लगातार फिर से प्रयास किए बिना विफलता को दर्ज करे। API के बढ़ने के साथ नए कोड और प्रकार सामने आ सकते हैं।
जहाँ उचित हो, स्टेटस पर आधारित फिर से प्रयास की ज्ञात नीति लागू करें। अन्यथा रुकें और जाँच के लिए कोड को उसकी अनुरोध ID के साथ लॉग करें।
त्रुटि गाइड त्रुटि प्रतिक्रिया का प्रारूप बताती है। त्रुटि संदर्भ में अलग-अलग कोड और उनसे उबरने के निर्देश दिए गए हैं।
संक्षेप में
संदेशों के बजाय कोड का मिलान करें।
Bird त्रुटि कोड का नाम कभी नहीं बदलता और उन्हें दोबारा उपयोग नहीं करता, लेकिन मानव-पठनीय संदेश बदल सकते हैं।
अस्थायी विफलताओं पर सीमा के साथ फिर से प्रयास करें।
अनुरोध दर की सीमा लागू होने पर प्रतीक्षा करें और अस्थायी सर्वर विफलताओं पर बढ़ते अंतराल के साथ फिर से प्रयास करें। तीन घंटे की आइडेम्पोटेंसी अवधि के भीतर वही कुंजी और बिल्कुल वही अनुरोध रखें।
वैलिडेशन विवरण पढ़ें।
E01001फ़ील्ड की समस्याएँdetailsमें देता है। हरparamसे उसके संदेश को प्रभावित इनपुट के साथ जोड़ें।अज्ञात त्रुटियों के लिए एक डिफ़ॉल्ट रास्ता रखें।
अपरिचित कोड और उनके अनुरोध ID लॉग करें, ताकि नई विफलताओं से आपका हैंडलर न टूटे।