Dominant la Limitació de Taxes al Client per a Integracions de l'API de Didit (CA)

La Regulació Proactiva és ClauImplementa la regulació al costat del client quan X-RateLimit-Remaining baixi del 15% per evitar errors 429 i assegurar la disponibilitat contínua del servei.

Retrocés Exponencial per a 429sUtilitza sempre una estratègia de retrocés exponencial (p. ex., 5s, 10s, 20s) en reintentar sol·licituds després de rebre una resposta 429, prevenint més violacions del límit de taxes.

Aprofita les Capçaleres de DiditLes capçaleres X-RateLimit-Limit, X-RateLimit-Remaining i X-RateLimit-Reset proporcionades per l'API de Didit són crucials per a una limitació de taxes dinàmica i intel·ligent al costat del client.

Didit Simplifica la IntegracióEls SDKs de Didit i l'enfocament "developer-first" agilitzen la implementació de les millors pràctiques per a la integració d'API, incloent mecanismes integrats i orientació per gestionar els límits de taxes de manera efectiva.

Entenent els Límits de Taxes de l'API i la seva Importància

Els límits de taxes de l'API són un aspecte fonamental dels serveis web moderns, dissenyats per protegir la infraestructura d'abusos, assegurar un ús just i mantenir l'estabilitat per a tots els usuaris. Per als desenvolupadors que s'integren amb serveis crítics com les plataformes de verificació d'identitat, comprendre i respectar aquests límits és primordial. En integrar-se amb l'API de Didit, trobaràs límits de taxes específics dissenyats per garantir operacions de verificació d'identitat fiables i d'alt rendiment.

Didit aplica múltiples capes de limitació de taxes, inclosos límits globals per a GET (300 sol·licituds per minut per aplicació) i per a punts finals d'escriptura/eliminació (300 sol·licituds per minut per aplicació), així com límits més restrictius específics per a punts finals per a operacions d'alt impacte. Per exemple, POST /v2/session/ (per crear fluxos de verificació) té un límit de 600 rpm, mentre que `GET /v2/session//decision/ (per recuperar decisions de sessió) i GET /session//generate-pdf/` estan limitats a 100 rpm a causa de la seva intensitat computacional.

Excedir aquests límits resulta en un codi d'estat HTTP 429 (Massa Sol·licituds). Tot i que això és una protecció del costat del servidor, una limitació de taxes efectiva al costat del client és crucial per evitar que la teva aplicació arribi a aquests límits, assegurant una experiència d'usuari fluida i un servei ininterromput. No implementar un maneig adequat al costat del client pot portar a un rendiment degradat, verificacions fallides i una mala impressió per als teus usuaris.

Estratègies per a la Limitació de Taxes al Client en JavaScript/TypeScript

La implementació de la limitació de taxes al costat del client implica anticipar i respondre als límits de l'API abans que siguin aplicats pel servidor. Això requereix una combinació de regulació proactiva i maneig d'errors reactiu. Aquí hi ha les estratègies clau:

1. Regulació Proactiva amb Capçaleres de Límits de Taxes

L'API de Didit inclou capçaleres específiques en les respostes 429 que són inestimables per a la limitació de taxes al costat del client: X-RateLimit-Limit, X-RateLimit-Remaining i X-RateLimit-Reset (en segons d'època). Has d'analitzar aquestes capçaleres i utilitzar-les per informar el comportament de les sol·licituds del teu client.

Un client robust:

• Monitoritzar X-RateLimit-Remaining: Segueix activament les sol·licituds restants. Quan aquest valor baixi d'un cert llindar (p. ex., 15% de X-RateLimit-Limit), el teu client hauria de començar a posar en cua les sol·licituds o a reduir la seva taxa de transmissió.
• Utilitzar X-RateLimit-Reset: Aquesta capçalera t'indica quan es reinicia la finestra actual del límit de taxes. Pots utilitzar aquesta marca de temps per programar quan el teu client pot reprendre amb seguretat les sol·licituds a tota velocitat.

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

async function makeDiditRequest(url: string, options: RequestInit): Promise<Response> {
  // En una aplicació real, gestionaries això globalment o per punt final
  let currentRateLimit: RateLimitHeaders | null = null;

  // Implementa una cua local o un mecanisme de retard basat en currentRateLimit
  // Per simplicitat, aquest exemple se centra en el maneig de la resposta.

  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. Implementació del Retrocés Exponencial per a Respostes 429

Quan el teu client rep una resposta 429, l'enfocament correcte no és reintentar immediatament. En canvi, implementa una estratègia de retrocés exponencial. Això implica esperar períodes cada vegada més llargs entre reintents, reduint la càrrega al servidor i augmentant la probabilitat d'èxit en intents posteriors. Les respostes 429 de Didit també inclouen una capçalera Retry-After, que proporciona una durada específica (en segons) per esperar abans de reintentar. Prioritza sempre aquesta capçalera si hi és present.

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; // Retroceso exponencial: 1s, 2s, 4s...
      console.warn(`S'ha assolit el límit de taxes. Reintentant en ${delay / 1000} segons...`);
      await new Promise(resolve => setTimeout(resolve, delay));
      return makeDiditRequestWithRetry(url, options, retries + 1);
    }

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

    return response;
  } catch (error) {
    console.error('La sol·licitud ha fallat:', error);
    throw error;
  }
}

// Exemple d'ús per a la recuperació de la decisió d'una sessió de Didit
// Aquest punt final està limitat a 100 rpm.
// makeDiditRequestWithRetry(`/v2/session/${sessionId}/decision/`, { method: 'GET' });

3. Utilització dels SDKs de Didit per a una Integració Agilitzada

Didit ofereix SDKs robustos per a diversos entorns, inclòs un SDK de JavaScript per a aplicacions web. Aquests SDKs sovint abstracten gran part de la complexitat de la interacció amb l'API, inclòs el maneig de patrons d'error comuns i la provisió de callbacks basats en esdeveniments per als fluxos de verificació. Tot i que la lògica explícita de limitació de taxes encara podria ser necessària per a crides API personalitzades i d'alt volum, l'ús dels SDKs per a fluxos de verificació orientats a l'usuari (com la Verificació d'Identitat, la Vivacitat Passiva i Activa, o l'Estimació d'Edat) simplifica significativament la integració.

Els SDKs estan dissenyats per a fluxos de treball orientats a l'usuari, on el teu backend inicia una sessió (POST /v2/session/) i el teu frontend renderitza la UI de verificació. L'SDK gestiona la interacció amb els serveis de Didit, reduint la càrrega directa de gestionar els límits de taxes de les crides API individuals des del costat del client durant el propi procés de verificació. En integrar-se amb l'SDK de JavaScript, l'inicialitzes amb un token de sessió del teu backend, i aquest gestiona el flux, proporcionant callbacks onSuccess, onError i onCancel.

Com Ajuda Didit

Didit està dissenyat per ser una plataforma d'identitat "developer-first" i nativa d'IA que proporciona opcions d'integració flexibles mentre manté un rendiment robust. El nostre enfocament en el disseny de l'API i els SDKs ajuda inherentment a gestionar els límits de taxes i a garantir operacions fluides:

• Documentació Clara dels Límits de Taxes: Didit proporciona documentació transparent i detallada sobre tots els límits de taxes de l'API, permetent als desenvolupadors planificar les seves integracions de manera efectiva.
• Capçaleres Informatives: La inclusió de les capçaleres X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset i Retry-After permet als desenvolupadors construir aplicacions client intel·ligents i autoregulades.
• Arquitectura Modular: El disseny modular de Didit significa que només integres les primitives d'identitat que necessites, com la Verificació d'Identitat per a comprovacions de documents, la Vivacitat Passiva i Activa per a la detecció de fraus, o l'Estimació d'Edat per a la verificació d'edat. Aquest enfocament dirigit pot ajudar a optimitzar els teus patrons de crides a l'API.
• SDKs per a Fluxos de Treball Simplificats: Els nostres SDKs web i mòbils agilitzen la integració de processos de verificació complexos orientats a l'usuari. En gestionar les complexitats del flux de verificació, incloent moltes crides API subjacents, els SDKs abstraen les preocupacions directes sobre els límits de taxes per a aquestes interaccions específiques, permetent-te centrar-te en la lògica de la teva aplicació.
• KYC Bàsic Gratuït: Didit ofereix KYC Bàsic Gratuït, permetent a les empreses començar amb serveis essencials de verificació d'identitat sense costos inicials, facilitant la prova i optimització de les teves estratègies d'integració, inclòs el maneig dels límits de taxes.

Preparat per Començar?

Vols veure Didit en acció? Demana una demostració gratuïta avui.

Comença a verificar identitats de forma gratuïta amb el pla gratuït de Didit.