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

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

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

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

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

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

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

डिडिट रेट लिमिटिंग की कई परतें लागू करता है, जिसमें GET (प्रति एप्लिकेशन प्रति मिनट 300 अनुरोध) और राइट/डिलीट एंडपॉइंट्स (प्रति एप्लिकेशन प्रति मिनट 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. सुव्यवस्थित एकीकरण के लिए डिडिट के एसडीके का उपयोग करना

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

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

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

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

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

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

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

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