Dominando a Limitação de Taxas do Lado do Cliente para Integrações da API Didit (PT-BR)

A Limitação Proativa é Fundamental Implemente a limitação do lado do cliente quando X-RateLimit-Remaining cair abaixo de 15% para evitar erros 429 e garantir a disponibilidade contínua do serviço.

Exponential Backoff para 429s Sempre use uma estratégia de "exponential backoff" (por exemplo, 5s, 10s, 20s) ao tentar novamente as requisições após receber uma resposta 429, prevenindo novas violações do limite de taxa.

Aproveite os Headers da Didit Os headers X-RateLimit-Limit, X-RateLimit-Remaining e X-RateLimit-Reset fornecidos pela API da Didit são cruciais para uma limitação de taxa dinâmica e inteligente do lado do cliente.

Didit Simplifica a Integração Os SDKs da Didit e a abordagem "developer-first" otimizam a implementação das melhores práticas para integração de API, incluindo mecanismos embutidos e orientação para lidar com limites de taxa de forma eficaz.

Entendendo os Limites de Taxa da API e Sua Importância

Os limites de taxa da API são um aspecto fundamental dos serviços web modernos, projetados para proteger a infraestrutura contra abusos, garantir o uso justo e manter a estabilidade para todos os usuários. Para desenvolvedores que se integram com serviços críticos como plataformas de verificação de identidade, entender e respeitar esses limites é primordial. Ao integrar-se com a API da Didit, você encontrará limites de taxa específicos projetados para garantir operações de verificação de identidade confiáveis e de alto desempenho.

A Didit impõe várias camadas de limitação de taxa, incluindo limites globais para GET (300 requisições por minuto por aplicação) e endpoints de Escrita/Exclusão (300 requisições por minuto por aplicação), bem como limites mais restritivos por endpoint para operações de alto impacto. Por exemplo, POST /v2/session/ (para criar fluxos de trabalho de verificação) tem um limite de 600 rpm, enquanto GET /v2/session/<id>/decision/ (para recuperar decisões de sessão) e GET /session/<id>/generate-pdf/ são limitados a 100 rpm devido à sua intensidade computacional.

Exceder esses limites resulta em um código de status HTTP 429 (Too Many Requests). Embora esta seja uma proteção do lado do servidor, a limitação de taxa eficaz do lado do cliente é crucial para evitar que sua aplicação atinja esses tetos, garantindo uma experiência de usuário tranquila e um serviço ininterrupto. A falha na implementação de um tratamento adequado do lado do cliente pode levar à degradação do desempenho, verificações falhas e uma má impressão para seus usuários.

Estratégias para Limitação de Taxas do Lado do Cliente em JavaScript/TypeScript

A implementação da limitação de taxas do lado do cliente envolve antecipar e responder aos limites da API antes que sejam impostos pelo servidor. Isso requer uma combinação de limitação proativa e tratamento reativo de erros. Aqui estão as principais estratégias:

1. Limitação Proativa com Headers de Limite de Taxa

A API da Didit inclui headers específicos em respostas 429 que são inestimáveis para a limitação de taxa do lado do cliente: X-RateLimit-Limit, X-RateLimit-Remaining e X-RateLimit-Reset (em segundos epoch). Você deve analisar esses headers e usá-los para informar o comportamento de requisição do seu cliente.

Um cliente robusto irá:

• Monitorar X-RateLimit-Remaining: Acompanhe ativamente as requisições restantes. Quando esse valor cair abaixo de um certo limite (por exemplo, 15% de X-RateLimit-Limit), seu cliente deve começar a enfileirar requisições ou diminuir sua taxa de transmissão.
• Utilizar X-RateLimit-Reset: Este header informa quando a janela atual do limite de taxa é redefinida. Você pode usar este timestamp para agendar quando seu cliente pode retomar com segurança as requisições em velocidade máxima.

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

async function makeDiditRequest(url: string, options: RequestInit): Promise<Response> {
  // Em um aplicativo real, você gerenciaria isso globalmente ou por endpoint
  let currentRateLimit: RateLimitHeaders | null = null;

  // Implemente uma fila local ou mecanismo de atraso baseado em currentRateLimit
  // Para simplificar, este exemplo foca no tratamento da 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(`Limite de Taxa: ${currentRateLimit.remaining}/${currentRateLimit.limit} requisições restantes. Reseta em ${new Date(currentRateLimit.reset * 1000).toLocaleTimeString()}.`);
  }

  return response;
}

2. Implementando o "Exponential Backoff" para Respostas 429

Quando seu cliente recebe uma resposta 429, a abordagem correta não é tentar novamente imediatamente. Em vez disso, implemente uma estratégia de "exponential backoff". Isso envolve esperar por períodos cada vez mais longos entre as tentativas, reduzindo a carga no servidor e aumentando a chance de sucesso em tentativas subsequentes. As respostas 429 da Didit também incluem um header Retry-After, que fornece uma duração específica (em segundos) para esperar antes de tentar novamente. Sempre priorize este header, se 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; // Exponential backoff: 1s, 2s, 4s...
      console.warn(`Limite de taxa atingido. Tentando novamente em ${delay / 1000} segundos...`);
      await new Promise(resolve => setTimeout(resolve, delay));
      return makeDiditRequestWithRetry(url, options, retries + 1);
    }

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

    return response;
  } catch (error) {
    console.error('Requisição falhou:', error);
    throw error;
  }
}

// Exemplo de uso para recuperação de decisão de sessão Didit
// Este endpoint é limitado a 100 rpm.
// makeDiditRequestWithRetry(`/v2/session/${sessionId}/decision/`, { method: 'GET' });

3. Utilizando os SDKs da Didit para uma Integração Simplificada

A Didit oferece SDKs robustos para vários ambientes, incluindo um SDK JavaScript para aplicações web. Esses SDKs frequentemente abstraem grande parte da complexidade da interação com a API, incluindo o tratamento de padrões de erro comuns e o fornecimento de callbacks orientados a eventos para fluxos de verificação. Embora a lógica explícita de limitação de taxas ainda possa ser necessária para chamadas de API personalizadas de alto volume, usar os SDKs para fluxos de verificação voltados para o usuário (como Verificação de ID, "Liveness" Passiva e Ativa, ou Estimativa de Idade) simplifica significativamente a integração.

Os SDKs são projetados para fluxos de trabalho voltados para o usuário, onde seu backend inicia uma sessão (POST /v2/session/) e seu frontend renderiza a interface de usuário de verificação. O SDK gerencia a interação com os serviços da Didit, reduzindo a carga direta de gerenciar limites de taxa de chamadas de API individuais do lado do cliente durante o próprio processo de verificação. Ao integrar com o SDK JavaScript, você o inicializa com um token de sessão do seu backend, e ele gerencia o fluxo, fornecendo callbacks onSuccess, onError e onCancel.

Como a Didit Ajuda

A Didit é projetada para ser uma plataforma de identidade "developer-first" e nativa de IA, que oferece opções de integração flexíveis, mantendo um desempenho robusto. Nossa abordagem ao design de APIs e SDKs ajuda inerentemente no gerenciamento de limites de taxa e na garantia de operações tranquilas:

• Documentação Clara de Limites de Taxa: A Didit fornece documentação transparente e detalhada sobre todos os limites de taxa da API, permitindo que os desenvolvedores planejem suas integrações de forma eficaz.
• Headers Informativos: A inclusão dos headers X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset e Retry-After capacita os desenvolvedores a construir aplicações cliente inteligentes e autorreguladoras.
• Arquitetura Modular: O design modular da Didit significa que você integra apenas as primitivas de identidade de que precisa, como Verificação de ID para verificações de documentos, "Liveness" Passiva e Ativa para detecção de fraudes, ou Estimativa de Idade para verificação de idade. Essa abordagem direcionada pode ajudar a otimizar seus padrões de chamada de API.
• SDKs para Fluxos de Trabalho Simplificados: Nossos SDKs web e móveis simplificam a integração de processos de verificação complexos voltados para o usuário. Ao lidar com as complexidades do fluxo de verificação, incluindo muitas chamadas de API subjacentes, os SDKs abstraem as preocupações diretas com limites de taxa para essas interações específicas, permitindo que você se concentre na lógica da sua aplicação.
• KYC Essencial Gratuito: A Didit oferece KYC Essencial Gratuito, permitindo que empresas comecem com serviços essenciais de verificação de identidade sem custos iniciais, tornando mais fácil testar e otimizar suas estratégias de integração, incluindo o manuseio de limites de taxa.

Pronto para Começar?

Pronto para ver a Didit em ação? Obtenha uma demonstração gratuita hoje.

Comece a verificar identidades gratuitamente com o nível gratuito da Didit.