डिडिट एपीआई एकीकरण के लिए क्लाइंट-साइड रेट लिमिटिंग में महारत हासिल करना

सक्रिय थ्रॉटलिंग महत्वपूर्ण है जब X-RateLimit-Remaining 15% से नीचे चला जाए तो 429 त्रुटियों से बचने और निरंतर सेवा उपलब्धता सुनिश्चित करने के लिए क्लाइंट-साइड थ्रॉटलिंग लागू करें।

429 के लिए एक्सपोनेंशियल बैकऑफ 429 प्रतिक्रिया प्राप्त होने के बाद अनुरोधों को पुन: प्रयास करते समय हमेशा एक एक्सपोनेंशियल बैकऑफ रणनीति (जैसे, 5s, 10s, 20s) का उपयोग करें, जिससे आगे रेट लिमिट उल्लंघनों को रोका जा सके।

डिडिट के हेडर का लाभ उठाएं डिडिट के एपीआई द्वारा प्रदान किए गए X-RateLimit-Limit, X-RateLimit-Remaining, और X-RateLimit-Reset हेडर गतिशील और बुद्धिमान क्लाइंट-साइड रेट लिमिटिंग के लिए महत्वपूर्ण हैं।

डिडिट एकीकरण को सरल बनाता है डिडिट के SDK और डेवलपर-प्रथम दृष्टिकोण एपीआई एकीकरण के लिए सर्वोत्तम प्रथाओं के कार्यान्वयन को सुव्यवस्थित करते हैं, जिसमें रेट लिमिट को प्रभावी ढंग से संभालने के लिए अंतर्निहित तंत्र और मार्गदर्शन शामिल हैं।

एपीआई रेट लिमिट और उनका महत्व समझना

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

डिडिट रेट लिमिट की कई परतें लागू करता है, जिसमें GET (प्रति एप्लिकेशन प्रति मिनट 300 अनुरोध) और Write/Delete एंडपॉइंट्स (प्रति एप्लिकेशन प्रति मिनट 300 अनुरोध) के लिए वैश्विक सीमाएं शामिल हैं, साथ ही उच्च-प्रभाव वाले ऑपरेशनों के लिए अधिक प्रतिबंधात्मक एंडपॉइंट-विशिष्ट सीमाएं भी शामिल हैं। उदाहरण के लिए, POST /v2/session/ (सत्यापन वर्कफ़्लो बनाने के लिए) की सीमा 600 आरपीएम है, जबकि GET /v2/session/<id>/decision/ (सत्र निर्णयों को पुनः प्राप्त करने के लिए) और GET /session/<id>/generate-pdf/ उनकी कम्प्यूटेशनल तीव्रता के कारण 100 आरपीएम पर सीमित हैं।

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

जावास्क्रिप्ट/टाइपस्क्रिप्ट में क्लाइंट-साइड रेट लिमिटिंग के लिए रणनीतियाँ

क्लाइंट-साइड रेट लिमिटिंग को लागू करने में एपीआई सीमाओं का अनुमान लगाना और प्रतिक्रिया देना शामिल है, इससे पहले कि वे सर्वर द्वारा लागू की जाएं। इसके लिए सक्रिय थ्रॉटलिंग और प्रतिक्रियाशील त्रुटि हैंडलिंग के संयोजन की आवश्यकता होती है। यहां प्रमुख रणनीतियाँ दी गई हैं:

1. रेट लिमिट हेडर के साथ सक्रिय थ्रॉटलिंग

डिडिट के एपीआई में 429 प्रतिक्रियाओं में विशिष्ट हेडर शामिल हैं जो क्लाइंट-साइड रेट लिमिटिंग के लिए अमूल्य हैं: X-RateLimit-Limit, X-RateLimit-Remaining, और X-RateLimit-Reset (इपोक सेकंड में)। आपको इन हेडर को पार्स करना चाहिए और उनका उपयोग अपने क्लाइंट के अनुरोध व्यवहार को सूचित करने के लिए करना चाहिए।

एक मजबूत क्लाइंट करेगा:

• X-RateLimit-Remaining की निगरानी करें: शेष अनुरोधों को सक्रिय रूप से ट्रैक करें। जब यह मान एक निश्चित सीमा (जैसे, X-RateLimit-Limit का 15%) से नीचे चला जाता है, तो आपके क्लाइंट को अनुरोधों को कतारबद्ध करना या अपनी संचरण दर को धीमा करना शुरू कर देना चाहिए।
• X-RateLimit-Reset का उपयोग करें: यह हेडर आपको बताता है कि वर्तमान रेट लिमिट विंडो कब रीसेट होती है। आप इस टाइमस्टैम्प का उपयोग यह शेड्यूल करने के लिए कर सकते हैं कि आपका क्लाइंट कब सुरक्षित रूप से पूर्ण-गति के अनुरोधों को फिर से शुरू कर सकता है।

interface RateLimitHeaders {
  limit: number;
  remaining: number;
  reset: number; // epoch seconds
}

async function makeDiditRequest(url: string, options: RequestInit): Promise<Response> {
  // In a real app, you'd manage these globally or per-endpoint
  let currentRateLimit: RateLimitHeaders | null = null;

  // Implement a local queue or delay mechanism based on currentRateLimit
  // For simplicity, this example focuses on response handling.

  const response = await fetch(url, options);

  const limit = response.headers.get('X-RateLimit-Limit');
  const remaining = response.headers.get('X-RateLimit-Remaining');
  const reset = response.headers.get('X-RateLimit-Reset');

  if (limit && remaining && reset) {
    currentRateLimit = {
      limit: parseInt(limit, 10),
      remaining: parseInt(remaining, 10),
      reset: parseInt(reset, 10),
    };
    console.log(`Rate Limit: ${currentRateLimit.remaining}/${currentRateLimit.limit} requests remaining. Resets at ${new Date(currentRateLimit.reset * 1000).toLocaleTimeString()}.`);
  }

  return response;
}

2. 429 प्रतिक्रियाओं के लिए एक्सपोनेंशियल बैकऑफ लागू करना

जब आपके क्लाइंट को 429 प्रतिक्रिया प्राप्त होती है, तो सही तरीका तुरंत पुनः प्रयास करना नहीं है। इसके बजाय, एक एक्सपोनेंशियल बैकऑफ रणनीति लागू करें। इसमें पुनः प्रयासों के बीच तेजी से लंबे समय तक प्रतीक्षा करना शामिल है, जिससे सर्वर पर लोड कम होता है और बाद के प्रयासों पर सफलता की संभावना बढ़ जाती है। डिडिट की 429 प्रतिक्रियाओं में एक Retry-After हेडर भी शामिल होता है, जो पुनः प्रयास करने से पहले प्रतीक्षा करने के लिए एक विशिष्ट अवधि (सेकंड में) प्रदान करता है। यदि मौजूद हो तो हमेशा इस हेडर को प्राथमिकता दें।

async function makeDiditRequestWithRetry(url: string, options: RequestInit, retries = 0): Promise<Response> {
  try {
    const response = await makeDiditRequest(url, options);

    if (response.status === 429) {
      const retryAfter = response.headers.get('Retry-After');
      const delay = retryAfter ? parseInt(retryAfter, 10) * 1000 : Math.pow(2, retries) * 1000; // Exponential backoff: 1s, 2s, 4s...
      console.warn(`Rate limit hit. Retrying in ${delay / 1000} seconds...`);
      await new Promise(resolve => setTimeout(resolve, delay));
      return makeDiditRequestWithRetry(url, options, retries + 1);
    }

    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }

    return response;
  } catch (error) {
    console.error('Request failed:', error);
    throw error;
  }
}

// Example usage for a Didit session decision retrieval
// This endpoint is limited to 100 rpm.
// makeDiditRequestWithRetry(`/v2/session/${sessionId}/decision/`, { method: 'GET' });

3. सुव्यवस्थित एकीकरण के लिए डिडिट के SDK का उपयोग करना

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

SDK को उपयोगकर्ता-सामने वर्कफ़्लो के लिए डिज़ाइन किया गया है, जहाँ आपका बैकएंड एक सत्र शुरू करता है (POST /v2/session/) और आपका फ्रंटएंड सत्यापन UI प्रस्तुत करता है। SDK डिडिट की सेवाओं के साथ इंटरैक्शन को संभालता है, जिससे सत्यापन प्रक्रिया के दौरान क्लाइंट-साइड से व्यक्तिगत एपीआई कॉल दर सीमाओं को प्रबंधित करने का सीधा बोझ कम हो जाता है। जावास्क्रिप्ट SDK के साथ एकीकृत करते समय, आप इसे अपने बैकएंड से एक सत्र टोकन के साथ इनिशियलाइज़ करते हैं, और यह प्रवाह को प्रबंधित करता है, onSuccess, onError, और onCancel कॉलबैक प्रदान करता है।

डिडिट कैसे मदद करता है

डिडिट को एक डेवलपर-प्रथम, एआई-नेटिव पहचान प्लेटफॉर्म के रूप में इंजीनियर किया गया है जो मजबूत प्रदर्शन को बनाए रखते हुए लचीले एकीकरण विकल्प प्रदान करता है। एपीआई डिज़ाइन और SDK के लिए हमारा दृष्टिकोण स्वाभाविक रूप से दर सीमाओं को प्रबंधित करने और सुचारू संचालन सुनिश्चित करने में मदद करता है:

• स्पष्ट दर सीमा प्रलेखन: डिडिट सभी एपीआई दर सीमाओं पर पारदर्शी और विस्तृत प्रलेखन प्रदान करता है, जिससे डेवलपर्स को अपने एकीकरण की प्रभावी ढंग से योजना बनाने की अनुमति मिलती है।
• सूचनात्मक हेडर: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, और Retry-After हेडर का समावेश डेवलपर्स को बुद्धिमान, आत्म-नियमन वाले क्लाइंट एप्लिकेशन बनाने में सशक्त बनाता है।
• मॉड्यूलर आर्किटेक्चर: डिडिट का मॉड्यूलर डिज़ाइन का मतलब है कि आप केवल उन पहचान आदिमों को एकीकृत करते हैं जिनकी आपको आवश्यकता है, जैसे दस्तावेज़ जांच के लिए आईडी सत्यापन, धोखाधड़ी का पता लगाने के लिए निष्क्रिय और सक्रिय जीवनता, या आयु सत्यापन के लिए आयु अनुमान। यह लक्षित दृष्टिकोण आपके एपीआई कॉल पैटर्न को अनुकूलित करने में मदद कर सकता है।
• सरलीकृत वर्कफ़्लो के लिए SDK: हमारे वेब और मोबाइल SDK जटिल उपयोगकर्ता-सामने सत्यापन प्रक्रियाओं के एकीकरण को सुव्यवस्थित करते हैं। सत्यापन प्रवाह की पेचीदगियों को संभालकर, जिसमें कई अंतर्निहित एपीआई कॉल शामिल हैं, SDK उन विशिष्ट इंटरैक्शन के लिए सीधी दर सीमा चिंताओं को अमूर्त करते हैं, जिससे आप अपने एप्लिकेशन लॉजिक पर ध्यान केंद्रित कर सकते हैं।
• फ्री कोर केवाईसी: डिडिट फ्री कोर केवाईसी प्रदान करता है, जिससे व्यवसायों को बिना किसी अग्रिम लागत के आवश्यक पहचान सत्यापन सेवाओं के साथ शुरुआत करने की अनुमति मिलती है, जिससे दर सीमा हैंडलिंग सहित आपकी एकीकरण रणनीतियों का परीक्षण और अनुकूलन करना आसान हो जाता है।

शुरू करने के लिए तैयार हैं?

डिडिट को कार्रवाई में देखने के लिए तैयार हैं? आज ही एक मुफ्त डेमो प्राप्त करें।

डिडिट के मुफ्त टियर के साथ मुफ्त में पहचान सत्यापित करना शुरू करें।