Client-seitiges Rate Limiting für Didit API-Integrationen meistern (DE)

Proaktives Drosseln ist entscheidendImplementieren Sie client-seitiges Drosseln, wenn X-RateLimit-Remaining unter 15 % fällt, um 429-Fehler zu vermeiden und eine kontinuierliche Dienstverfügbarkeit zu gewährleisten.

Exponentieller Backoff bei 429sVerwenden Sie immer eine exponentielle Backoff-Strategie (z. B. 5s, 10s, 20s) beim Wiederholen von Anfragen nach einer 429-Antwort, um weitere Überschreitungen der Ratenbegrenzung zu verhindern.

Didits Header nutzenDie von Didits API bereitgestellten Header X-RateLimit-Limit, X-RateLimit-Remaining und X-RateLimit-Reset sind entscheidend für eine dynamische und intelligente client-seitige Ratenbegrenzung.

Didit vereinfacht die IntegrationDidits SDKs und der entwicklerzentrierte Ansatz optimieren die Implementierung bewährter Verfahren für die API-Integration, einschließlich integrierter Mechanismen und Anleitungen für den effektiven Umgang mit Ratenbegrenzungen.

API-Ratenbegrenzungen und ihre Bedeutung verstehen

API-Ratenbegrenzungen sind ein grundlegender Aspekt moderner Webdienste, die dazu dienen, die Infrastruktur vor Missbrauch zu schützen, eine faire Nutzung zu gewährleisten und die Stabilität für alle Benutzer aufrechtzuerhalten. Für Entwickler, die sich in kritische Dienste wie Identitätsprüfungsplattformen integrieren, ist das Verständnis und die Einhaltung dieser Grenzen von größter Bedeutung. Bei der Integration mit Didits API werden Sie auf spezifische Ratenbegrenzungen stoßen, die darauf ausgelegt sind, zuverlässige und hochleistungsfähige Identitätsprüfungsoperationen zu gewährleisten.

Didit setzt mehrere Ebenen von Ratenbegrenzungen durch, einschließlich globaler Limits für GET (300 Anfragen pro Minute pro Anwendung) und Write/Delete-Endpunkte (300 Anfragen pro Minute pro Anwendung), sowie restriktivere endpunktspezifische Limits für Operationen mit hoher Auswirkung. Zum Beispiel hat POST /v2/session/ (zum Erstellen von Verifizierungs-Workflows) ein Limit von 600 U/min, während GET /v2/session/<id>/decision/ (zum Abrufen von Session-Entscheidungen) und GET /session/<id>/generate-pdf/ aufgrund ihrer Rechenintensität auf 100 U/min begrenzt sind.

Das Überschreiten dieser Limits führt zu einem HTTP-Statuscode 429 (Too Many Requests). Obwohl dies ein serverseitiger Schutz ist, ist eine effektive client-seitige Ratenbegrenzung entscheidend, um zu verhindern, dass Ihre Anwendung diese Grenzen erreicht, und um ein reibungsloses Benutzererlebnis und einen unterbrechungsfreien Dienst zu gewährleisten. Wenn keine ordnungsgemäße client-seitige Behandlung implementiert wird, kann dies zu einer verminderten Leistung, fehlgeschlagenen Verifizierungen und einem schlechten Eindruck bei Ihren Benutzern führen.

Strategien für client-seitiges Rate Limiting in JavaScript/TypeScript

Die Implementierung einer client-seitigen Ratenbegrenzung beinhaltet das Antizipieren und Reagieren auf API-Limits, bevor sie vom Server durchgesetzt werden. Dies erfordert eine Kombination aus proaktiver Drosselung und reaktiver Fehlerbehandlung. Hier sind die wichtigsten Strategien:

1. Proaktive Drosselung mit Rate Limit Headern

Didits API enthält spezifische Header in 429-Antworten, die für die client-seitige Ratenbegrenzung von unschätzbarem Wert sind: X-RateLimit-Limit, X-RateLimit-Remaining und X-RateLimit-Reset (in Epochensekunden). Sie sollten diese Header analysieren und sie verwenden, um das Anforderungsverhalten Ihres Clients zu informieren.

Ein robuster Client wird:

• X-RateLimit-Remaining überwachen: Verfolgen Sie aktiv die verbleibenden Anfragen. Wenn dieser Wert unter einen bestimmten Schwellenwert fällt (z. B. 15 % von X-RateLimit-Limit), sollte Ihr Client beginnen, Anfragen in die Warteschlange zu stellen oder seine Übertragungsrate zu verlangsamen.
• X-RateLimit-Reset verwenden: Dieser Header teilt Ihnen mit, wann das aktuelle Ratenbegrenzungsfenster zurückgesetzt wird. Sie können diesen Zeitstempel verwenden, um zu planen, wann Ihr Client sicher wieder Anfragen mit voller Geschwindigkeit senden kann.

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. Implementierung des exponentiellen Backoffs für 429-Antworten

Wenn Ihr Client eine 429-Antwort erhält, besteht der richtige Ansatz nicht darin, sofort einen erneuten Versuch zu unternehmen. Implementieren Sie stattdessen eine exponentielle Backoff-Strategie. Dies beinhaltet das Warten auf immer längere Zeiträume zwischen den Wiederholungsversuchen, wodurch die Last auf dem Server reduziert und die Erfolgswahrscheinlichkeit bei nachfolgenden Versuchen erhöht wird. Didits 429-Antworten enthalten auch einen Retry-After-Header, der eine spezifische Dauer (in Sekunden) angibt, die vor einem erneuten Versuch gewartet werden soll. Priorisieren Sie diesen Header immer, falls vorhanden.

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. Nutzung von Didits SDKs für eine optimierte Integration

Didit bietet robuste SDKs für verschiedene Umgebungen, einschließlich eines JavaScript SDK für Webanwendungen. Diese SDKs abstrahieren oft einen Großteil der Komplexität der API-Interaktion, einschließlich der Behandlung häufiger Fehlermuster und der Bereitstellung ereignisgesteuerter Callbacks für Verifizierungsabläufe. Während eine explizite Ratenbegrenzungslogik für volumenstarke, benutzerdefinierte API-Aufrufe weiterhin notwendig sein könnte, vereinfacht die Verwendung der SDKs für benutzerseitige Verifizierungsabläufe (wie ID-Verifizierung, passive & aktive Lebenderkennung oder Altersschätzung) die Integration erheblich.

Die SDKs sind für benutzerseitige Workflows konzipiert, bei denen Ihr Backend eine Sitzung initiiert (POST /v2/session/) und Ihr Frontend die Verifizierungs-UI rendert. Das SDK handhabt die Interaktion mit Didits Diensten und reduziert die direkte Belastung der Verwaltung individueller API-Aufrufratenbegrenzungen von Client-Seite während des Verifizierungsprozesses selbst. Bei der Integration mit dem JavaScript SDK initialisieren Sie es mit einem Sitzungstoken von Ihrem Backend, und es verwaltet den Ablauf, indem es onSuccess-, onError- und onCancel-Callbacks bereitstellt.

Wie Didit hilft

Didit wurde als entwicklerzentrierte, KI-native Identitätsplattform entwickelt, die flexible Integrationsoptionen bietet und gleichzeitig eine robuste Leistung aufrechterhält. Unser Ansatz für API-Design und SDKs hilft von Natur aus bei der Verwaltung von Ratenbegrenzungen und der Gewährleistung eines reibungslosen Betriebs:

• Klare Dokumentation zu Ratenbegrenzungen: Didit bietet transparente und detaillierte Dokumentation zu allen API-Ratenbegrenzungen, sodass Entwickler ihre Integrationen effektiv planen können.
• Informative Header: Die Einbeziehung von X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset und Retry-After-Headern ermöglicht es Entwicklern, intelligente, selbstregulierende Client-Anwendungen zu erstellen.
• Modulare Architektur: Didits modularer Aufbau bedeutet, dass Sie nur die Identitäts-Primitiven integrieren, die Sie benötigen, wie z. B. ID-Verifizierung für Dokumentenprüfungen, passive & aktive Lebenderkennung zur Betrugserkennung oder Altersschätzung zur Altersverifizierung. Dieser zielgerichtete Ansatz kann dazu beitragen, Ihre API-Aufrufmuster zu optimieren.
• SDKs für vereinfachte Workflows: Unsere Web- und Mobil-SDKs optimieren die Integration komplexer benutzerseitiger Verifizierungsprozesse. Durch die Handhabung der Feinheiten des Verifizierungsablaufs, einschließlich vieler zugrunde liegender API-Aufrufe, abstrahieren die SDKs direkte Ratenbegrenzungsbedenken für diese spezifischen Interaktionen, sodass Sie sich auf Ihre Anwendungslogik konzentrieren können.
• Kostenloses Core KYC: Didit bietet kostenloses Core KYC an, das es Unternehmen ermöglicht, mit wesentlichen Identitätsprüfungsdiensten ohne Vorabkosten zu beginnen, was das Testen und Optimieren Ihrer Integrationsstrategien, einschließlich der Ratenbegrenzungsbehandlung, erleichtert.

Bereit zum Start?

Möchten Sie Didit in Aktion sehen? Fordern Sie noch heute eine kostenlose Demo an.

Beginnen Sie mit der kostenlosen Überprüfung von Identitäten mit Didits kostenlosem Tarif.