Didit API連携におけるクライアントサイドレート制限の習得 (JA)

積極的なスロットリングが鍵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 rpmの制限がありますが、GET /v2/session//decision/（セッション決定取得用）とGET /session//generate-pdf/は計算負荷が高いため、100 rpmに制限されています。

これらの制限を超えると、429 HTTPステータスコード（Too Many Requests）が返されます。これはサーバー側の保護ですが、アプリケーションがこれらの上限に達するのを防ぎ、スムーズなユーザーエクスペリエンスと中断のないサービスを確保するためには、効果的なクライアントサイドのレート制限が不可欠です。適切なクライアントサイド処理を実装しないと、パフォーマンスの低下、確認の失敗、ユーザーへの悪い印象につながる可能性があります。

JavaScript/TypeScriptにおけるクライアントサイドレート制限の戦略

クライアントサイドのレート制限を実装するには、API制限がサーバーによって適用される前に、それを予測し対応する必要があります。これには、積極的なスロットリングとリアクティブなエラー処理の組み合わせが必要です。主な戦略は次のとおりです。

1. レート制限ヘッダーによる積極的なスロットリング

DiditのAPIは、429応答にクライアントサイドのレート制限に非常に役立つ特定のヘッダーを含んでいます：X-RateLimit-Limit、X-RateLimit-Remaining、およびX-RateLimit-Reset（エポック秒）。これらのヘッダーを解析し、クライアントのリクエスト動作を通知するために使用する必要があります。

堅牢なクライアントは以下のことを行います：

• 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がフローを管理し、onSuccess、onError、およびonCancelコールバックを提供します。

Diditがどのように役立つか

Diditは、開発者ファーストのAIネイティブなIDプラットフォームとして設計されており、堅牢なパフォーマンスを維持しながら柔軟な統合オプションを提供します。API設計とSDKに対する私たちのアプローチは、レート制限の管理とスムーズな操作の確保に本質的に役立ちます。

• 明確なレート制限ドキュメント：Diditは、すべてのAPIレート制限に関する透明で詳細なドキュメントを提供し、開発者が統合を効果的に計画できるようにします。
• 情報提供ヘッダー：X-RateLimit-Limit、X-RateLimit-Remaining、X-RateLimit-Reset、およびRetry-Afterヘッダーの包含により、開発者はインテリジェントで自己規制的なクライアントアプリケーションを構築できます。
• モジュラーアーキテクチャ：Diditのモジュラー設計は、ドキュメントチェック用のID確認、不正検出用のパッシブおよびアクティブな生体認証、または年齢確認用の年齢推定など、必要なIDプリミティブのみを統合できることを意味します。このターゲットを絞ったアプローチは、API呼び出しパターンを最適化するのに役立ちます。
• 合理化されたワークフローのためのSDK：当社のウェブおよびモバイルSDKは、複雑なユーザー向け検証プロセスの統合を合理化します。多くの基盤となるAPI呼び出しを含む検証フローの複雑さを処理することで、SDKはそれらの特定のインタラクションに対する直接的なレート制限の懸念を抽象化し、アプリケーションロジックに集中できるようにします。
• 無料のコアKYC：Diditは無料のコアKYCを提供しており、企業は初期費用なしで必須の本人確認サービスを開始でき、レート制限処理を含む統合戦略のテストと最適化を容易にします。

始める準備はできましたか？

Diditの動作をご覧になりませんか？ 今すぐ無料デモをお試しください。

Diditの無料ティアで無料で本人確認を開始しましょう。