एक रिक्वेस्ट सर्वर तक पहुँच सकती है, भले ही आपके एप्लिकेशन को कभी रिस्पॉन्स न मिले। फिर से भेजना शुरू करने से पहले आपके इंटीग्रेशन को उस अनिश्चितता के लिए एक पॉलिसी चाहिए।
Bird के REST SDK TypeScript, Python, Go और PHP के लिए वह रिक्वेस्ट हैंडलिंग प्रदान करते हैं। Swift और Kotlin पैकेज REST API के बजाय Realtime सब्सक्रिप्शन को सर्व करते हैं।
Bird SDK क्या हैंडल करता है?
SDK दोहराई जा सकने वाली रिक्वेस्ट मेकैनिक्स को हैंडल करता है, जिसमें फिर से प्रयास, रूटिंग और डुप्लीकेट प्रोटेक्शन शामिल हैं।
म्यूटेटिंग ऑपरेशन के लिए यह एक Idempotency-Key जनरेट करता है और उसे इंटरनल फिर से प्रयासों में बनाए रखता है। इससे Bird खोए हुए रिस्पॉन्स के बाद उसी ऑपरेशन को पहचान सकता है।
यह Retry-After का सम्मान करने वाले बैकऑफ़ के साथ क्षणिक विफलताओं पर फिर से प्रयास करता है। इसलिए 429 के बाद अगले प्रयास से पहले प्रतीक्षा होती है। ऑथेंटिकेशन और वैलिडेशन विफलताओं के लिए अभी भी आपके एप्लिकेशन को उनका कारण ठीक करना होगा।
List हेल्पर आपके इटरेट करने पर क्रमिक पेज फ़ेच करते हैं। रीजन रूटिंग आपकी key के प्रीफ़िक्स से होस्ट चुनती है। Webhook हेल्पर डिकोडेड इवेंट लौटाने से पहले रॉ रिक्वेस्ट बॉडी को वेरिफ़ाई करते हैं।
आपके एप्लिकेशन को अभी भी डुप्लीकेट बिज़नेस एक्शन को रिजेक्ट करना होगा। उसे अपना अधूरा काम भी रिकवर करना होगा। Idempotency रिक्वेस्ट फिर से प्रयासों और एप्लिकेशन गारंटी के बीच की सीमा बताता है।
अगर मेरे ऑपरेशन के लिए कोई typed method नहीं है तो?
बिना किसी dedicated typed method के public endpoint कॉल करने के लिए SDK की HTTP verb methods का उपयोग करें।
ये methods रिक्वेस्ट हैंडलिंग बनाए रखती हैं, जिसमें फिर से प्रयास और रीजन सेलेक्शन शामिल हैं। आप API रेफ़रेंस से पाथ और पेलोड सप्लाई करते हैं।
किसी typed method का अनुपस्थित होना ऑपरेशन को अनुपलब्ध नहीं बनाता। कॉलिंग method बदलने से यह नहीं बदलता कि आपका क्रेडेंशियल किन endpoints को एक्सेस कर सकता है।
उदाहरण के लिए, साइन-इन CLI या MCP सेशन के ज़रिए API key रोटेट करें, या डैशबोर्ड का उपयोग करें। CLI या MCP सर्वर को api_keys:write वाले व्यक्ति से ऑथराइज़ेशन चाहिए। केवल API key रखने वाली सर्विस यह नहीं कर सकती।
मुझे HTTP को सीधे कब कॉल करना चाहिए?
जब उपलब्ध SDK आपकी भाषा, रनटाइम या डिपेंडेंसी पॉलिसी में फिट न हों तो सीधे कॉल करें।
क्लाइंट लाइब्रेरी चुनने से पहले किसी endpoint को इंस्पेक्ट करने के लिए भी आप डायरेक्ट रिक्वेस्ट का उपयोग कर सकते हैं। Bird दोनों तरीकों के लिए एक ही public HTTP API का उपयोग करता है।
अगर आप किसी अन्य भाषा में जनरेटेड मॉडल चाहते हैं तो OpenAPI स्पेसिफ़िकेशन से क्लाइंट जनरेट करें। इसके रनटाइम व्यवहार की अलग से जाँच करें, क्योंकि जनरेटर इस बात में भिन्न होते हैं कि वे क्या लागू करते हैं।
डायरेक्ट रिक्वेस्ट के लिए, अपनी key के रीजन का होस्ट चुनें। एक ऑपरेशन के फिर से प्रयासों में एक ही idempotency key का पुन: उपयोग करें। पेजिनेशन कर्सर फ़ॉलो करें। अपरिवर्तित बॉडी पर इनकमिंग webhook सिग्नेचर वेरिफ़ाई करें।
फिर से प्रयास और टाइमआउट सीमाएँ सेट करें ताकि कोई विफल डिपेंडेंसी एप्लिकेशन रिक्वेस्ट को अनिश्चित काल तक खुला न रख सके।
फिर से प्रयास मेरे टाइमआउट को कैसे प्रभावित करते हैं?
फिर से प्रयास कुल कॉल को एक प्रयास के टाइमआउट से अधिक लंबा बना सकता है।
SDK डिफ़ॉल्ट रूप से दो फिर से प्रयासों की अनुमति देते हैं, जिससे एक कॉल में अधिकतम तीन प्रयास होते हैं। TypeScript, Python और Go प्रति प्रयास 60 सेकंड का डिफ़ॉल्ट टाइमआउट रखते हैं। तीन टाइम-आउट प्रयास इसलिए फिर से प्रयास प्रतीक्षा जोड़ने से पहले लगभग तीन मिनट ले सकते हैं।
PHP आपके द्वारा इंजेक्ट किए गए HTTP क्लाइंट पर कॉन्फ़िगर किए गए टाइमआउट का उपयोग करता है। इसे वहीं सेट करें ताकि रिक्वेस्ट की अवधि सीमित रहे।
किसी भी बाहरी डेडलाइन के साथ फिर से प्रयास बजट को समायोजित करें। SDK कॉन्सेप्ट गाइड हर भाषा के लिए कॉन्फ़िगरेशन नाम और प्रति-कॉल ओवरराइड का वर्णन करती है।
SDK के चारों ओर असीमित फिर से प्रयास लूप न जोड़ें। अलग-अलग SDK कॉल अलग-अलग keys जनरेट करते हैं, जब तक कि आप पूरे ऑपरेशन के लिए एक स्थिर idempotency key सप्लाई न करें।
मुझे कौन सा इंटीग्रेशन चुनना चाहिए?
रिक्वेस्ट हैंडलिंग की वह न्यूनतम मात्रा चुनें जो आपके एप्लिकेशन को स्वयं संभालनी होगी।
- Bird SDK: आपकी भाषा समर्थित है और इसकी डिपेंडेंसी आपके रनटाइम में फिट होती हैं।
- SDK verb method: ऑपरेशन public है लेकिन उसके लिए कोई dedicated typed method नहीं है।
- जनरेटेड क्लाइंट: आपको कोई अन्य भाषा या अपने खुद के जनरेशन कन्वेंशन चाहिए।
- डायरेक्ट HTTP: आप डिपेंडेंसी को नियंत्रित करना और रिक्वेस्ट पॉलिसी खुद लागू करना चाहते हैं।
संक्षेप में
SDK दोहराए जाने वाले रिक्वेस्ट प्लंबिंग को संभालते हैं।
ये idempotency keys, फिर से प्रयास, रीजनल रूटिंग, पेजिनेशन और webhook सत्यापन को मैनेज करते हैं। आपका एप्लिकेशन अपने बिज़नेस नियमों का मालिक बना रहता है।
किसी typed method का न होना ज़रूरी नहीं कि आपको रोक दे।
SDK की HTTP verb methods का उपयोग करके typed surface से बाहर के public ऑपरेशन कॉल करें। रिक्वेस्ट हैंडलिंग फिर भी लागू रहती है।
एप्लिकेशन के फिर से प्रयासों में एक ही key रखें।
अलग-अलग SDK कॉल अलग-अलग idempotency keys बनाते हैं, जब तक कि आप ऑपरेशन के लिए key खुद सप्लाई न करें।
हर प्रयास के लिए बजट रखें।
डिफ़ॉल्ट रूप से दो फिर से प्रयास सक्षम हैं। TypeScript, Python और Go हर प्रयास को अलग से टाइम आउट करते हैं। PHP अपने HTTP क्लाइंट के टाइमआउट का उपयोग करता है।