Dominando la Limitación de Tasa del Lado del Cliente para Integraciones con la API de Didit (ES)

La Limitación Proactiva es Clave Implementa la limitación del lado del cliente cuando X-RateLimit-Remaining caiga por debajo del 15% para evitar errores 429 y asegurar la disponibilidad continua del servicio.

Retroceso Exponencial para 429s Siempre utiliza una estrategia de retroceso exponencial (por ejemplo, 5s, 10s, 20s) al reintentar solicitudes después de recibir una respuesta 429, previniendo futuras infracciones del límite de tasa.

Aprovecha los Encabezados de Didit Los encabezados X-RateLimit-Limit, X-RateLimit-Remaining y X-RateLimit-Reset proporcionados por la API de Didit son cruciales para una limitación de tasa dinámica e inteligente del lado del cliente.

Didit Simplifica la Integración Los SDKs de Didit y su enfoque centrado en el desarrollador agilizan la implementación de las mejores prácticas para la integración de APIs, incluyendo mecanismos integrados y guía para manejar eficazmente los límites de tasa.

Entendiendo los Límites de Tasa de API y Su Importancia

Los límites de tasa de API son un aspecto fundamental de los servicios web modernos, diseñados para proteger la infraestructura del abuso, asegurar un uso justo y mantener la estabilidad para todos los usuarios. Para los desarrolladores que se integran con servicios críticos como las plataformas de verificación de identidad, comprender y respetar estos límites es primordial. Al integrarse con la API de Didit, encontrará límites de tasa específicos diseñados para garantizar operaciones de verificación de identidad fiables y de alto rendimiento.

Didit aplica múltiples capas de limitación de tasa, incluyendo límites globales para GET (300 solicitudes por minuto por aplicación) y puntos finales de escritura/eliminación (300 solicitudes por minuto por aplicación), así como límites más restrictivos específicos de los puntos finales para operaciones de alto impacto. Por ejemplo, POST /v2/session/ (para crear flujos de trabajo de verificación) tiene un límite de 600 rpm, mientras que GET /v2/session/<id>/decision/ (para recuperar decisiones de sesión) y GET /session/<id>/generate-pdf/ están limitados a 100 rpm debido a su intensidad computacional.

Exceder estos límites resulta en un código de estado HTTP 429 (Demasiadas Solicitudes). Si bien esta es una protección del lado del servidor, una limitación de tasa efectiva del lado del cliente es crucial para evitar que su aplicación alcance estos techos, asegurando una experiencia de usuario fluida y un servicio ininterrumpido. No implementar un manejo adecuado del lado del cliente puede llevar a un rendimiento degradado, verificaciones fallidas y una mala impresión para sus usuarios.

Estrategias para la Limitación de Tasa del Lado del Cliente en JavaScript/TypeScript

La implementación de la limitación de tasa del lado del cliente implica anticipar y responder a los límites de la API antes de que sean aplicados por el servidor. Esto requiere una combinación de limitación proactiva y manejo reactivo de errores. Aquí se presentan estrategias clave:

1. Limitación Proactiva con Encabezados de Límite de Tasa

La API de Didit incluye encabezados específicos en las respuestas 429 que son invaluables para la limitación de tasa del lado del cliente: X-RateLimit-Limit, X-RateLimit-Remaining y X-RateLimit-Reset (en segundos epoch). Debe analizar estos encabezados y usarlos para informar el comportamiento de solicitud de su cliente.

Un cliente robusto:

• Monitoreará X-RateLimit-Remaining: Seguirá activamente las solicitudes restantes. Cuando este valor caiga por debajo de un cierto umbral (por ejemplo, 15% de X-RateLimit-Limit), su cliente debería comenzar a encolar solicitudes o a reducir su tasa de transmisión.
• Utilizará X-RateLimit-Reset: Este encabezado le indica cuándo se reinicia la ventana actual del límite de tasa. Puede usar esta marca de tiempo para programar cuándo su cliente puede reanudar de forma segura las solicitudes a toda velocidad.

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

async function makeDiditRequest(url: string, options: RequestInit): Promise<Response> {
  // En una aplicación real, los gestionarías globalmente o por punto final
  let currentRateLimit: RateLimitHeaders | null = null;

  // Implementar una cola local o un mecanismo de retardo basado en currentRateLimit
  // Por simplicidad, este ejemplo se centra en el manejo de la respuesta.

  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(`Límite de Tasa: ${currentRateLimit.remaining}/${currentRateLimit.limit} solicitudes restantes. Se reinicia a las ${new Date(currentRateLimit.reset * 1000).toLocaleTimeString()}.`);
  }

  return response;
}

2. Implementando el Retroceso Exponencial para las Respuestas 429

Cuando su cliente recibe una respuesta 429, el enfoque correcto no es reintentar inmediatamente. En su lugar, implemente una estrategia de retroceso exponencial. Esto implica esperar períodos cada vez más largos entre reintentos, reduciendo la carga en el servidor y aumentando la probabilidad de éxito en intentos posteriores. Las respuestas 429 de Didit también incluyen un encabezado Retry-After, que proporciona una duración específica (en segundos) para esperar antes de reintentar. Siempre priorice este encabezado si está presente.

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(`Límite de tasa alcanzado. Reintentando en ${delay / 1000} segundos...`);
      await new Promise(resolve => setTimeout(resolve, delay));
      return makeDiditRequestWithRetry(url, options, retries + 1);
    }

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

    return response;
  } catch (error) {
    console.error('La solicitud falló:', error);
    throw error;
  }
}

// Ejemplo de uso para la recuperación de una decisión de sesión de Didit
// Este punto final está limitado a 100 rpm.
// makeDiditRequestWithRetry(`/v2/session/${sessionId}/decision/`, { method: 'GET' });

3. Utilizando los SDKs de Didit para una Integración Optimizada

Didit ofrece SDKs robustos para varios entornos, incluyendo un SDK de JavaScript para aplicaciones web. Estos SDKs a menudo abstraen gran parte de la complejidad de la interacción de la API, incluyendo el manejo de patrones de error comunes y la provisión de callbacks controlados por eventos para flujos de verificación. Si bien la lógica explícita de limitación de tasa aún podría ser necesaria para llamadas de API personalizadas de alto volumen, el uso de los SDKs para flujos de verificación orientados al usuario (como Verificación de Identificación, Prueba de Vida Pasiva y Activa, o Estimación de Edad) simplifica significativamente la integración.

Los SDKs están diseñados para flujos de trabajo orientados al usuario, donde su backend inicia una sesión (POST /v2/session/) y su frontend renderiza la interfaz de usuario de verificación. El SDK maneja la interacción con los servicios de Didit, reduciendo la carga directa de gestionar los límites de tasa de llamadas individuales de la API desde el lado del cliente durante el propio proceso de verificación. Al integrarse con el SDK de JavaScript, lo inicializa con un token de sesión de su backend, y este gestiona el flujo, proporcionando callbacks onSuccess, onError y onCancel.

Cómo Ayuda Didit

Didit está diseñado para ser una plataforma de identidad nativa de IA, enfocada en el desarrollador, que ofrece opciones de integración flexibles manteniendo un rendimiento robusto. Nuestro enfoque en el diseño de la API y los SDKs ayuda intrínsecamente a gestionar los límites de tasa y a garantizar operaciones fluidas:

• Documentación Clara de Límites de Tasa: Didit proporciona documentación transparente y detallada sobre todos los límites de tasa de la API, permitiendo a los desarrolladores planificar sus integraciones de manera efectiva.
• Encabezados Informativos: La inclusión de los encabezados X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset y Retry-After capacita a los desarrolladores para construir aplicaciones cliente inteligentes y autorreguladas.
• Arquitectura Modular: El diseño modular de Didit significa que solo integra las primitivas de identidad que necesita, como Verificación de Identificación para la revisión de documentos, Prueba de Vida Pasiva y Activa para la detección de fraude, o Estimación de Edad para la verificación de edad. Este enfoque dirigido puede ayudar a optimizar sus patrones de llamadas a la API.
• SDKs para Flujos de Trabajo Simplificados: Nuestros SDKs web y móviles agilizan la integración de procesos complejos de verificación orientados al usuario. Al manejar las complejidades del flujo de verificación, incluyendo muchas llamadas a la API subyacentes, los SDKs abstraen las preocupaciones directas de los límites de tasa para esas interacciones específicas, permitiéndole centrarse en la lógica de su aplicación.
• KYC Básico Gratuito: Didit ofrece KYC Básico Gratuito, lo que permite a las empresas comenzar con servicios esenciales de verificación de identidad sin costos iniciales, facilitando la prueba y optimización de sus estrategias de integración, incluido el manejo de límites de tasa.

¿Listo para Empezar?

¿Listo para ver Didit en acción? Obtenga una demostración gratuita hoy mismo.

Comience a verificar identidades de forma gratuita con el nivel gratuito de Didit.