Maîtriser la Limitation de Débit Côté Client pour les Intégrations API Didit (FR)

La Maîtrise Proactive est EssentielleImplémentez une limitation côté client lorsque X-RateLimit-Remaining tombe en dessous de 15 % pour éviter les erreurs 429 et assurer une disponibilité continue du service.

Backoff Exponentiel pour les 429Utilisez toujours une stratégie de backoff exponentiel (par exemple, 5s, 10s, 20s) lors de la nouvelle tentative de requêtes après avoir reçu une réponse 429, évitant ainsi de nouvelles violations de la limite de débit.

Exploitez les En-têtes de DiditLes en-têtes X-RateLimit-Limit, X-RateLimit-Remaining et X-RateLimit-Reset fournis par l'API de Didit sont cruciaux pour une limitation de débit côté client dynamique et intelligente.

Didit Simplifie l'IntégrationLes SDK de Didit et son approche axée sur les développeurs simplifient la mise en œuvre des meilleures pratiques pour l'intégration API, y compris les mécanismes intégrés et les conseils pour gérer efficacement les limites de débit.

Comprendre les Limites de Débit des API et Leur Importance

Les limites de débit des API sont un aspect fondamental des services web modernes, conçues pour protéger l'infrastructure contre les abus, assurer une utilisation équitable et maintenir la stabilité pour tous les utilisateurs. Pour les développeurs intégrant des services critiques comme les plateformes de vérification d'identité, comprendre et respecter ces limites est primordial. Lors de l'intégration avec l'API de Didit, vous rencontrerez des limites de débit spécifiques conçues pour garantir des opérations de vérification d'identité fiables et performantes.

Didit applique plusieurs couches de limitation de débit, y compris des limites globales pour les requêtes GET (300 requêtes par minute par application) et les points de terminaison d'écriture/suppression (300 requêtes par minute par application), ainsi que des limites plus restrictives spécifiques aux points de terminaison pour les opérations à fort impact. Par exemple, POST /v2/session/ (pour créer des flux de vérification) a une limite de 600 tr/min, tandis que `GET /v2/session//decision/ (pour récupérer les décisions de session) et GET /session//generate-pdf/` sont plafonnés à 100 tr/min en raison de leur intensité de calcul.

Le dépassement de ces limites entraîne un code d'état HTTP 429 (Trop de requêtes). Bien qu'il s'agisse d'une protection côté serveur, une limitation de débit côté client efficace est cruciale pour empêcher votre application d'atteindre ces plafonds, garantissant une expérience utilisateur fluide et un service ininterrompu. Ne pas implémenter une gestion côté client appropriée peut entraîner une dégradation des performances, des vérifications échouées et une mauvaise impression pour vos utilisateurs.

Stratégies de Limitation de Débit Côté Client en JavaScript/TypeScript

L'implémentation de la limitation de débit côté client implique d'anticiper et de répondre aux limites de l'API avant qu'elles ne soient appliquées par le serveur. Cela nécessite une combinaison de limitation proactive et de gestion réactive des erreurs. Voici les stratégies clés :

1. Limitation Proactive avec les En-têtes de Limite de Débit

L'API de Didit inclut des en-têtes spécifiques dans les réponses 429 qui sont inestimables pour la limitation de débit côté client : X-RateLimit-Limit, X-RateLimit-Remaining et X-RateLimit-Reset (en secondes epoch). Vous devez analyser ces en-têtes et les utiliser pour informer le comportement de requête de votre client.

Un client robuste va :

• Surveiller X-RateLimit-Remaining : Suivre activement les requêtes restantes. Lorsque cette valeur tombe en dessous d'un certain seuil (par exemple, 15 % de X-RateLimit-Limit), votre client doit commencer à mettre en file d'attente les requêtes ou à ralentir son taux de transmission.
• Utiliser X-RateLimit-Reset : Cet en-tête vous indique quand la fenêtre de limite de débit actuelle se réinitialise. Vous pouvez utiliser cet horodatage pour planifier quand votre client peut reprendre en toute sécurité les requêtes à pleine vitesse.

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. Implémentation du Backoff Exponentiel pour les Réponses 429

Lorsque votre client reçoit une réponse 429, la bonne approche n'est pas de réessayer immédiatement. Au lieu de cela, implémentez une stratégie de backoff exponentiel. Cela implique d'attendre des périodes de plus en plus longues entre les nouvelles tentatives, réduisant la charge sur le serveur et augmentant les chances de succès lors des tentatives ultérieures. Les réponses 429 de Didit incluent également un en-tête Retry-After, qui fournit une durée spécifique (en secondes) à attendre avant de réessayer. Priorisez toujours cet en-tête s'il est présent.

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. Utilisation des SDK de Didit pour une Intégration Simplifiée

Didit propose des SDK robustes pour divers environnements, y compris un SDK JavaScript pour les applications web. Ces SDK abstraient souvent une grande partie de la complexité de l'interaction API, y compris la gestion des modèles d'erreur courants et la fourniture de rappels basés sur les événements pour les flux de vérification. Bien qu'une logique de limitation de débit explicite puisse encore être nécessaire pour les appels API personnalisés à volume élevé, l'utilisation des SDK pour les flux de vérification destinés aux utilisateurs (comme la vérification d'identité, la vivacité passive et active ou l'estimation de l'âge) simplifie considérablement l'intégration.

Les SDK sont conçus pour les flux de travail destinés aux utilisateurs, où votre backend initie une session (POST /v2/session/) et votre frontend rend l'interface utilisateur de vérification. Le SDK gère l'interaction avec les services de Didit, réduisant le fardeau direct de la gestion des limites de débit des appels API individuels côté client pendant le processus de vérification lui-même. Lors de l'intégration avec le SDK JavaScript, vous l'initialisez avec un jeton de session de votre backend, et il gère le flux, fournissant des rappels onSuccess, onError et onCancel.

Comment Didit Aide

Didit est conçu pour être une plateforme d'identité axée sur les développeurs et nativement IA, offrant des options d'intégration flexibles tout en maintenant des performances robustes. Notre approche de la conception d'API et des SDK aide intrinsèquement à gérer les limites de débit et à assurer des opérations fluides :

• Documentation Claire sur les Limites de Débit : Didit fournit une documentation transparente et détaillée sur toutes les limites de débit de l'API, permettant aux développeurs de planifier efficacement leurs intégrations.
• En-têtes Informatifs : L'inclusion des en-têtes X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset et Retry-After permet aux développeurs de créer des applications clientes intelligentes et autorégulées.
• Architecture Modulaire : La conception modulaire de Didit signifie que vous n'intégrez que les primitives d'identité dont vous avez besoin, telles que la vérification d'identité pour les contrôles de documents, la vivacité passive et active pour la détection de fraude, ou l'estimation de l'âge pour la vérification de l'âge. Cette approche ciblée peut aider à optimiser vos modèles d'appels API.
• SDK pour des Flux de Travail Simplifiés : Nos SDK web et mobiles rationalisent l'intégration de processus de vérification complexes destinés aux utilisateurs. En gérant les subtilités du flux de vérification, y compris de nombreux appels API sous-jacents, les SDK abstraient les préoccupations directes de limite de débit pour ces interactions spécifiques, vous permettant de vous concentrer sur la logique de votre application.
• Core KYC Gratuit : Didit propose un Core KYC gratuit, permettant aux entreprises de démarrer avec des services de vérification d'identité essentiels sans coûts initiaux, ce qui facilite le test et l'optimisation de vos stratégies d'intégration, y compris la gestion des limites de débit.

Prêt à Commencer ?

Prêt à voir Didit en action ? Obtenez une démo gratuite dès aujourd'hui.

Commencez à vérifier les identités gratuitement avec le niveau gratuit de Didit.