Entwicklerleitfaden: Didit API-Aufrufe für CDN Edge Caching optimieren (DE)

Ratenbegrenzungen verstehenDidit erzwingt globale und endpunktspezifische Ratenbegrenzungen, um die API-Stabilität aufrechtzuerhalten, und stellt die Header X-RateLimit-Limit, X-RateLimit-Remaining und X-RateLimit-Reset für die clientseitige Drosselung bereit.

Exponentielles Backoff implementierenFür 429-Antworten integrieren Sie eine exponentielle Backoff-Strategie (z. B. 5s → 10s → 20s), um temporäre API-Überlastungen elegant zu handhaben und clientseitige Ratenbegrenzungsverletzungen zu vermeiden.

CDN für statische Assets nutzenObwohl die Kern-API von Didit nicht von traditionellen CDNs gecacht werden kann, optimieren Sie die statischen Assets Ihrer Anwendung (JS, CSS, Bilder) über CDN, um Ladezeiten zu reduzieren und die wahrgenommene Leistung zu verbessern.

Didits LeistungsarchitekturDidits KI-native, global verteilte Infrastruktur bietet von Natur aus geringe Latenz und hohe Verfügbarkeit, was sie zu einer idealen Wahl für leistungskritische Anforderungen an die Identitätsprüfung macht.

In der heutigen schnelllebigen digitalen Landschaft zählt jede Millisekunde. Für Entwickler, die Identitätsprüfungsdienste integrieren, ist die Optimierung von API-Aufrufen für Geschwindigkeit und Effizienz von größter Bedeutung. Während Content Delivery Networks (CDNs) oft mit dem Caching statischer Assets in Verbindung gebracht werden, ist es entscheidend, zu verstehen, wie man am besten mit API-Diensten interagiert, insbesondere mit solchen, die für dynamische, Echtzeit-Operationen wie die Identitätsprüfung konzipiert sind, um die Gesamtleistung der Anwendung zu gewährleisten. Dieser Leitfaden befasst sich mit der Optimierung Ihrer Didit API-Integrationen, wobei der Schwerpunkt auf Ratenbegrenzung, effizienten Aufrufmuster und der Art und Weise liegt, wie Didits Architektur von Natur aus hohe Leistung unterstützt.

Didits API-Ratenbegrenzungen verstehen

Didit implementiert, wie jeder robuste API-Dienst, Ratenbegrenzungen, um Stabilität und faire Nutzung für alle Clients zu gewährleisten. Diese Begrenzungen sind entscheidend, um Missbrauch zu verhindern und eine konsistente Leistung aufrechtzuerhalten. Das Verstehen und Einhalten dieser Begrenzungen ist der erste Schritt zu optimierten API-Interaktionen.

Didit erzwingt mehrere Ebenen von Ratenbegrenzungen:

• Globale Begrenzungen: Für allgemeine GET-Endpunkte gibt es ein Limit von 300 Anfragen pro Minute pro Anwendung. Ebenso haben POST, PATCH und DELETE (Schreib-/Lösch-)Endpunkte ebenfalls eine globale Obergrenze von 300 Anfragen pro Minute pro Anwendung.
• Endpunktspezifische Begrenzungen: Bestimmte hochwirksame Operationen haben restriktivere Begrenzungen. Zum Beispiel ist POST /v2/session/ (zum Erstellen von Verifizierungssitzungen, oft unter Einbeziehung von Didits ID-Verifizierung oder Altersschätzungsprodukten) auf 600 Anfragen pro Minute begrenzt. Das Abrufen von Sitzungsentscheidungen (`GET /v2/session//decision/) ist auf 100 Anfragen pro Minute gedrosselt, um übermäßiges Polling zu verhindern, und die PDF-Generierung (GET /session//generate-pdf/`) ist aufgrund ihrer CPU-intensiven Natur ebenfalls auf 100 Anfragen pro Minute begrenzt.

Wenn eine Ratenbegrenzung überschritten wird, antwortet Didits API mit dem Statuscode 429 Too Many Requests. Entscheidend ist, dass diese Antworten hilfreiche Header enthalten:

• X-RateLimit-Limit: Die maximale Anzahl erlaubter Anfragen.
• X-RateLimit-Remaining: Die Anzahl der verbleibenden Anfragen im aktuellen Fenster.
• X-RateLimit-Reset: Die Zeit (in Epoch-Sekunden), zu der sich das aktuelle Ratenbegrenzungsfenster zurücksetzt.

Durch die Überwachung dieser Header kann Ihre Anwendung proaktiv selbst drosseln, unnötige 429-Fehler vermeiden und einen reibungsloseren Betriebsablauf für Dienste wie Didits AML Screening oder Liveness Detection gewährleisten.

Implementierung intelligenter clientseitiger Drosselung und Backoff

Ein effektiver clientseitiger Umgang mit Ratenbegrenzungen ist entscheidend für eine widerstandsfähige Integration. So geht's:

1. Ratenbegrenzungs-Header beobachten: Implementieren Sie Logik, um den Header X-RateLimit-Remaining zu lesen. Wenn dieser Wert unter einen bestimmten Schwellenwert fällt (z. B. 15 % von X-RateLimit-Limit), sollte Ihr Client beginnen, seine Anfragerate zu verlangsamen.

2. Exponentielles Backoff für 429er: Dies ist eine entscheidende Strategie. Wenn Ihre Anwendung eine 429-Antwort erhält, sollte sie eine Pause einlegen, bevor sie die Anfrage erneut versucht. Anstatt sofortiger Wiederholungen implementieren Sie einen exponentiellen Backoff-Algorithmus. Warten Sie zum Beispiel 5 Sekunden, dann 10 Sekunden, dann 20 Sekunden usw. Dies verhindert eine weitere Überlastung der API und ermöglicht das Zurücksetzen des Ratenbegrenzungsfensters. Didits Retry-After-Header kann auch Ihre Backoff-Strategie beeinflussen.

3. Protokollieren und Benachrichtigen: Verfolgen Sie, wann Ratenbegrenzungen erreicht und wann Wiederholungsversuche ausgelöst werden. Dies liefert wertvolle Einblicke in die Nutzungsmuster Ihrer Anwendung und kann helfen, Bereiche für Optimierung zu identifizieren oder die Notwendigkeit anzuzeigen, eine höhere Begrenzung vom Didit-Support für bestimmte Anwendungsfälle anzufordern.

Die Rolle des CDN Edge Caching bei der API-Leistung

Während Didits Kern-Identitätsprüfungs-APIs, wie die für ID-Verifizierung, 1:1-Gesichtsabgleich oder NFC-Verifizierung, dynamische Echtzeitverarbeitung beinhalten, die nicht effektiv von einem CDN zwischengespeichert werden kann (da jede Anfrage einzigartig ist und eine neue Berechnung erfordert), spielen CDNs dennoch eine Rolle für die Gesamtleistung Ihrer Anwendung.

CDNs eignen sich hervorragend zum Caching statischer Inhalte (Bilder, JavaScript, CSS-Dateien, Videos) an Edge-Standorten näher an Ihren Benutzern. Indem Sie diese Assets von einem CDN bereitstellen, reduzieren Sie die Last auf Ihrem Ursprungsserver und verringern die Latenz für Ihre Benutzer. Dies verbessert die wahrgenommene Leistung Ihrer Anwendung und lässt das gesamte Erlebnis, einschließlich des Identitätsprüfungsablaufs, viel schneller und reaktionsschneller erscheinen.

Wenn Ihre Anwendung beispielsweise einen Didit-Workflow verwendet, der eine webbasierte Benutzeroberfläche beinhaltet (z. B. zum Sammeln von Dokumenten-Uploads oder Liveness-Detection-Selfies), können die statischen Assets für diese Benutzeroberfläche über ein CDN bereitgestellt werden. Während die API-Aufrufe an Didits Backend zur Verarbeitung der Verifizierung direkt erfolgen, beeinflusst die Geschwindigkeit der umgebenden Anwendungsumgebung die Benutzerzufriedenheit erheblich.

Didits KI-native Architektur für unübertroffene Leistung

Didit wurde von Grund auf als KI-native, entwicklerfreundliche Identitätsplattform entwickelt. Diese architektonische Wahl bietet von Natur aus erhebliche Leistungsvorteile, die Ihre CDN-Strategien für statische Assets ergänzen:

• Globale Verteilung: Didits Infrastruktur ist global verteilt und gewährleistet eine geringe Latenz für Benutzer unabhängig von ihrem geografischen Standort. Das bedeutet, dass API-Aufrufe an Didits Verifizierungsendpunkte an das nächstgelegene Rechenzentrum weitergeleitet werden, wodurch die Netzwerk-Reisezeit minimiert wird.
• Optimiert für Echtzeit: Produkte wie Passive & Active Liveness und 1:1 Face Match sind für die Echtzeitverarbeitung konzipiert und nutzen fortschrittliche KI-Modelle, die schnell und effizient ausgeführt werden.
• Skalierbarkeit: Didits modulare Architektur ist für Skalierbarkeit ausgelegt und kann hohe Volumina von Verifizierungsanfragen ohne Leistungsverschlechterung verarbeiten, selbst während Spitzenzeiten. Dies ist entscheidend für Anwendungen, die einen hohen Durchsatz für Dienste wie Telefon- und E-Mail-Verifizierung oder Adressnachweis erfordern.
• Entwicklerfreundliche APIs: Saubere, gut dokumentierte APIs stellen sicher, dass Entwickler effizient integrieren können, wodurch die Entwicklungszeit und potenzielle integrationsbedingte Leistungsengpässe reduziert werden. Der programmatische Registrierungsprozess, der nur zwei API-Aufrufe erfordert, ist ein Beispiel für diesen entwicklerfreundlichen Ansatz.

Durch die Konzentration auf effiziente API-Nutzungspraktiken, wie z. B. intelligentes Ratenlimit-Handling und exponentielles Backoff, können Sie Didits leistungsstarkes, KI-natives Backend voll ausschöpfen, um ein nahtloses und schnelles Identitätsprüfungs-Erlebnis zu bieten.

Wie Didit hilft

Didit wurde entwickelt, um ein leistungsstarkes, zuverlässiges Identitätsprüfungs-Erlebnis zu bieten. Unsere KI-native Plattform bietet eine modulare Architektur, die es Ihnen ermöglicht, spezifische Identitäts-Primitive wie ID-Verifizierung (mit OCR, MRZ und Barcode-Unterstützung), Passive & Active Liveness, 1:1 Face Match und AML Screening & Monitoring nach Bedarf zu integrieren. Diese Modularität bedeutet, dass Sie nur die Ressourcen nutzen, die Sie benötigen, wodurch sowohl Kosten als auch Leistung optimiert werden. Didits kostenloses Core KYC-Angebot, ohne Einrichtungsgebühren und mit einem Pay-per-erfolgreiche-Prüfung-Modell, macht den Einstieg unglaublich einfach. Unsere global verteilte Infrastruktur stellt sicher, dass Ihre API-Aufrufe von geringer Latenz und hoher Verfügbarkeit profitieren, wodurch die Notwendigkeit des traditionellen CDN-Cachings von API-Antworten weniger relevant wird, da die dynamische Natur der Identitätsprüfung eine Echtzeitverarbeitung erfordert. Wir befähigen Entwickler mit einer robusten, skalierbaren Lösung, die von Natur aus Geschwindigkeit und Effizienz priorisiert, sodass Sie sich auf die Entwicklung großartiger Anwendungen konzentrieren können, während wir die Komplexität der Identitätsvertrauenswürdigkeit übernehmen.

Bereit zum Start?

Bereit, Didit in Aktion zu sehen? Holen Sie sich noch heute eine kostenlose Demo.

Beginnen Sie kostenlos mit der Verifizierung von Identitäten mit Didits kostenlosem Tarif.