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

A Otimização Proativa é Fundamental Implemente a otimizaçã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 Utilize sempre uma estratégia de "exponential backoff" (e.g., 5s, 10s, 20s) ao tentar novamente pedidos após receber uma resposta 429, prevenindo mais violações do limite de taxas.

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

A Didit Simplifica a Integração Os SDKs da Didit e a abordagem "developer-first" simplificam a implementação de boas práticas para a integração de APIs, incluindo mecanismos e orientações incorporados para gerir eficazmente os limites de taxas.

Compreender os Limites de Taxa da API e a Sua Importância

Os limites de taxa da API são um aspeto fundamental dos serviços web modernos, concebidos para proteger a infraestrutura contra abusos, garantir uma utilização justa e manter a estabilidade para todos os utilizadores. Para os programadores que integram com serviços críticos como plataformas de verificação de identidade, compreender e respeitar estes limites é primordial. Ao integrar com a API da Didit, encontrará limites de taxa específicos concebidos para garantir operações de verificação de identidade fiáveis e de alto desempenho.

A Didit impõe várias camadas de limitação de taxa, incluindo limites globais para GET (300 pedidos por minuto por aplicação) e "endpoints" de Gravação/Eliminação (300 pedidos por minuto por aplicação), bem como limites mais restritivos específicos de "endpoints" 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//decision/ (para recuperar decisões de sessão) e GET /session//generate-pdf/` estão limitados a 100 rpm devido à sua intensidade computacional.

Exceder estes limites resulta num código de estado HTTP 429 (Too Many Requests). Embora esta seja uma proteção do lado do servidor, uma limitação de taxa eficaz do lado do cliente é crucial para evitar que a sua aplicação atinja estes tetos, garantindo uma experiência de utilizador suave e um serviço ininterrupto. A falha na implementação de um tratamento adequado do lado do cliente pode levar a um desempenho degradado, verificações falhadas e uma má impressão para os seus utilizadores.

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

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

1. Otimização Proativa com Cabeçalhos de Limite de Taxa

A API da Didit inclui cabeçalhos 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"). Deve analisar estes cabeçalhos e usá-los para informar o comportamento de pedido do seu cliente.

Um cliente robusto irá:

• Monitorizar X-RateLimit-Remaining: Acompanhar ativamente os pedidos restantes. Quando este valor cai abaixo de um certo limiar (e.g., 15% de X-RateLimit-Limit), o seu cliente deve começar a enfileirar pedidos ou a diminuir a sua taxa de transmissão.
• Utilizar X-RateLimit-Reset: Este cabeçalho indica quando a janela atual de limite de taxa é reiniciada. Pode usar este carimbo de data/hora para programar quando o seu cliente pode retomar com segurança os pedidos em velocidade máxima.

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

async function makeDiditRequest(url: string, options: RequestInit): Promise<Response> {
  // Numa aplicação real, geriria isto globalmente ou por "endpoint"
  let currentRateLimit: RateLimitHeaders | null = null;

  // Implementar uma fila local ou mecanismo de atraso baseado em currentRateLimit
  // Para simplificar, este exemplo foca-se no tratamento de respostas.

  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} pedidos restantes. Reinicia às ${new Date(currentRateLimit.reset * 1000).toLocaleTimeString()}.`);
  }

  return response;
}

2. Implementar "Exponential Backoff" para Respostas 429

Quando o seu cliente recebe uma resposta 429, a abordagem correta não é tentar novamente imediatamente. Em vez disso, implemente uma estratégia de "exponential backoff". Isto envolve esperar por períodos cada vez mais longos entre as tentativas, reduzindo a carga no servidor e aumentando a probabilidade de sucesso em tentativas subsequentes. As respostas 429 da Didit também incluem um cabeçalho Retry-After, que fornece uma duração específica (em segundos) para esperar antes de tentar novamente. Dê sempre prioridade a este cabeçalho, 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. A tentar 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('Pedido falhou:', error);
    throw error;
  }
}

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

3. Utilizar 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. Estes SDKs frequentemente abstraem grande parte da complexidade da interação da API, incluindo o tratamento de padrões de erro comuns e o fornecimento de "callbacks" orientados por eventos para fluxos de verificação. Embora a lógica explícita de limitação de taxa ainda possa ser necessária para chamadas de API personalizadas de alto volume, usar os SDKs para fluxos de verificação voltados para o utilizador (como Verificação de ID, "Liveness" Passiva e Ativa, ou Estimativa de Idade) simplifica significativamente a integração.

Os SDKs são concebidos para fluxos de trabalho voltados para o utilizador, onde o seu "backend" inicia uma sessão (POST /v2/session/) e o seu "frontend" renderiza a interface de utilizador de verificação. O SDK gere a interação com os serviços da Didit, reduzindo o ónus direto de gerir limites de taxa de chamadas de API individuais do lado do cliente durante o processo de verificação em si. Ao integrar com o SDK JavaScript, inicializa-o com um token de sessão do seu "backend", e este gere o fluxo, fornecendo "callbacks" onSuccess, onError e onCancel.

Como a Didit Ajuda

A Didit foi projetada para ser uma plataforma de identidade "AI-native" e "developer-first" que oferece opções de integração flexíveis, mantendo um desempenho robusto. A nossa abordagem ao design da API e aos SDKs ajuda inerentemente na gestão dos limites de taxa e na garantia de operações suaves:

• Documentação Clara sobre Limites de Taxa: A Didit fornece documentação transparente e detalhada sobre todos os limites de taxa da API, permitindo que os programadores planeiem as suas integrações de forma eficaz.
• Cabeçalhos Informativos: A inclusão dos cabeçalhos X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset e Retry-After capacita os programadores a construir aplicações cliente inteligentes e auto-reguladoras.
• Arquitetura Modular: O design modular da Didit significa que apenas integra os primitivos de identidade de que necessita, como Verificação de ID para verificações de documentos, "Liveness" Passiva e Ativa para deteção de fraude, ou Estimativa de Idade para verificação de idade. Esta abordagem direcionada pode ajudar a otimizar os seus padrões de chamadas de API.
• SDKs para Fluxos de Trabalho Simplificados: Os nossos SDKs web e móveis simplificam a integração de processos de verificação complexos voltados para o utilizador. Ao lidar com as complexidades do fluxo de verificação, incluindo muitas chamadas de API subjacentes, os SDKs abstraem as preocupações diretas com os limites de taxa para essas interações específicas, permitindo-lhe concentrar-se na lógica da sua aplicação.
• KYC Essencial Gratuito: A Didit oferece KYC Essencial Gratuito, permitindo que as empresas comecem com serviços essenciais de verificação de identidade sem custos iniciais, tornando mais fácil testar e otimizar as suas estratégias de integração, incluindo o tratamento 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.