Didit API 통합을 위한 클라이언트 측 속도 제한 마스터하기 (KO)

사전 예방적 스로틀링이 중요합니다. X-RateLimit-Remaining이 15% 미만으로 떨어지면 429 오류를 방지하고 지속적인 서비스 가용성을 보장하기 위해 클라이언트 측 스로틀링을 구현하세요.

429 오류에 대한 지수 백오프. 429 응답을 받은 후 요청을 재시도할 때는 항상 지수 백오프 전략(예: 5초, 10초, 20초)을 사용하여 추가적인 속도 제한 위반을 방지하세요.

Didit의 헤더를 활용하세요. Didit API가 제공하는 X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset 헤더는 동적이고 지능적인 클라이언트 측 속도 제한에 매우 중요합니다.

Didit은 통합을 간소화합니다. Didit의 SDK와 개발자 우선 접근 방식은 속도 제한을 효과적으로 처리하기 위한 내장 메커니즘 및 지침을 포함하여 API 통합을 위한 모범 사례 구현을 간소화합니다.

API 속도 제한 및 그 중요성 이해하기

API 속도 제한은 현대 웹 서비스의 근본적인 측면으로, 인프라를 남용으로부터 보호하고, 공정한 사용을 보장하며, 모든 사용자의 안정성을 유지하도록 설계되었습니다. 신원 확인 플랫폼과 같은 중요한 서비스와 통합하는 개발자에게 이러한 제한을 이해하고 존중하는 것은 가장 중요합니다. Didit의 API와 통합할 때 안정적이고 고성능의 신원 확인 작업을 보장하도록 설계된 특정 속도 제한을 접하게 될 것입니다.

Didit은 GET(애플리케이션당 분당 300회 요청) 및 쓰기/삭제 엔드포인트(애플리케이션당 분당 300회 요청)에 대한 전역 제한과 같이 여러 계층의 속도 제한을 적용하며, 고영향 작업에 대해서는 더 엄격한 엔드포인트별 제한을 적용합니다. 예를 들어, POST /v2/session/(확인 워크플로 생성용)은 분당 600회 요청으로 제한되며, GET /v2/session//decision/(세션 결정 검색용) 및 GET /session//generate-pdf/는 연산 집약도가 높기 때문에 분당 100회 요청으로 제한됩니다.

이러한 제한을 초과하면 429 HTTP 상태 코드(너무 많은 요청)가 발생합니다. 이는 서버 측 보호 기능이지만, 효과적인 클라이언트 측 속도 제한은 애플리케이션이 이러한 한도에 도달하는 것을 방지하여 원활한 사용자 경험과 중단 없는 서비스를 보장하는 데 중요합니다. 적절한 클라이언트 측 처리를 구현하지 못하면 성능 저하, 확인 실패 및 사용자에게 나쁜 인상을 줄 수 있습니다.

JavaScript/TypeScript에서 클라이언트 측 속도 제한을 위한 전략

클라이언트 측 속도 제한을 구현하려면 서버에서 적용되기 전에 API 제한을 예상하고 대응해야 합니다. 이를 위해서는 사전 예방적 스로틀링과 반응적 오류 처리가 결합되어야 합니다. 다음은 주요 전략입니다.

1. 속도 제한 헤더를 사용한 사전 예방적 스로틀링

Didit의 API는 클라이언트 측 속도 제한에 매우 유용한 특정 헤더(X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset(에포크 초))를 429 응답에 포함합니다. 이러한 헤더를 구문 분석하고 이를 사용하여 클라이언트의 요청 동작을 알려야 합니다.

강력한 클라이언트는 다음과 같이 작동합니다.

• X-RateLimit-Remaining 모니터링: 남은 요청을 적극적으로 추적합니다. 이 값이 특정 임계값(예: X-RateLimit-Limit의 15%) 미만으로 떨어지면 클라이언트는 요청을 대기시키거나 전송 속도를 늦추기 시작해야 합니다.
• X-RateLimit-Reset 활용: 이 헤더는 현재 속도 제한 창이 언제 재설정되는지 알려줍니다. 이 타임스탬프를 사용하여 클라이언트가 언제 안전하게 최대 속도로 요청을 재개할 수 있는지 예약할 수 있습니다.

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. 429 응답에 대한 지수 백오프 구현

클라이언트가 429 응답을 받을 때 올바른 접근 방식은 즉시 재시도하는 것이 아닙니다. 대신, 지수 백오프 전략을 구현해야 합니다. 이는 재시도 간에 점점 더 긴 시간을 기다려 서버의 부하를 줄이고 후속 시도에서 성공할 가능성을 높이는 것을 포함합니다. Didit의 429 응답에는 Retry-After 헤더도 포함되어 있으며, 이는 재시도하기 전에 기다려야 하는 특정 기간(초)을 제공합니다. 이 헤더가 있는 경우 항상 우선적으로 고려하세요.

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. 간소화된 통합을 위한 Didit의 SDK 활용

Didit은 웹 애플리케이션용 JavaScript SDK를 포함하여 다양한 환경을 위한 강력한 SDK를 제공합니다. 이러한 SDK는 일반적인 오류 패턴 처리 및 확인 흐름에 대한 이벤트 기반 콜백 제공을 포함하여 API 상호 작용의 많은 복잡성을 추상화합니다. 고볼륨의 사용자 지정 API 호출에 대해서는 명시적인 속도 제한 로직이 여전히 필요할 수 있지만, 사용자 대면 확인 흐름(예: ID 확인, 수동 및 능동 생체 인식 또는 연령 추정)에 SDK를 사용하면 통합이 크게 간소화됩니다.

SDK는 사용자 대면 워크플로를 위해 설계되었으며, 백엔드에서 세션을 시작하고(POST /v2/session/) 프런트엔드에서 확인 UI를 렌더링합니다. SDK는 Didit 서비스와의 상호 작용을 처리하여 확인 프로세스 자체에서 클라이언트 측에서 개별 API 호출 속도 제한을 관리하는 직접적인 부담을 줄입니다. JavaScript SDK와 통합할 때 백엔드에서 세션 토큰으로 SDK를 초기화하면 SDK가 흐름을 관리하고 onSuccess, onError 및 onCancel 콜백을 제공합니다.

Didit이 도움이 되는 방법

Didit은 강력한 성능을 유지하면서 유연한 통합 옵션을 제공하는 개발자 우선, AI 기반 신원 플랫폼으로 설계되었습니다. API 설계 및 SDK에 대한 우리의 접근 방식은 속도 제한을 관리하고 원활한 작업을 보장하는 데 본질적으로 도움이 됩니다.

• 명확한 속도 제한 문서: Didit은 모든 API 속도 제한에 대한 투명하고 상세한 문서를 제공하여 개발자가 통합을 효과적으로 계획할 수 있도록 합니다.
• 정보 제공 헤더: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset 및 Retry-After 헤더를 포함하면 개발자가 지능적이고 자체 조절되는 클라이언트 애플리케이션을 구축할 수 있습니다.
• 모듈식 아키텍처: Didit의 모듈식 설계는 문서 확인을 위한 ID 확인, 사기 탐지를 위한 수동 및 능동 생체 인식 또는 연령 확인을 위한 연령 추정과 같이 필요한 신원 기본 요소만 통합함을 의미합니다. 이 타겟팅된 접근 방식은 API 호출 패턴을 최적화하는 데 도움이 될 수 있습니다.
• 간소화된 워크플로를 위한 SDK: 당사의 웹 및 모바일 SDK는 복잡한 사용자 대면 확인 프로세스의 통합을 간소화합니다. 많은 기본 API 호출을 포함하여 확인 흐름의 복잡성을 처리함으로써 SDK는 해당 특정 상호 작용에 대한 직접적인 속도 제한 문제를 추상화하여 애플리케이션 로직에 집중할 수 있도록 합니다.
• 무료 핵심 KYC: Didit은 무료 핵심 KYC를 제공하여 기업이 선불 비용 없이 필수 신원 확인 서비스를 시작할 수 있도록 하여 속도 제한 처리를 포함한 통합 전략을 테스트하고 최적화하기 쉽게 만듭니다.

시작할 준비가 되셨습니까?

Didit의 작동 방식을 확인하고 싶으십니까? 지금 무료 데모를 받으세요.

Didit의 무료 티어로 신원을 무료로 확인하세요.