Passer au contenu principal
Didit lève 7,5 M$ pour bâtir l'infrastructure pour l'identité et la fraude
Didit
Retour au blog
Blog · 7 mars 2026

Guide du développeur : Optimisation des appels API Didit pour la mise en cache CDN Edge (FR)

Optimisez vos intégrations d'API Didit pour des performances et une évolutivité inégalées en exploitant les stratégies de mise en cache CDN.

Par DiditMis à jour le
optimizing-didit-api-calls-cdn-edge-caching-performance.png

Comprendre les limites de débitDidit applique des limites de débit globales et spécifiques aux points de terminaison pour maintenir la stabilité de l'API, fournissant les en-têtes X-RateLimit-Limit, X-RateLimit-Remaining et X-RateLimit-Reset pour la limitation côté client.

Implémenter un backoff exponentielPour les réponses 429, intégrez une stratégie de backoff exponentiel (par exemple, 5s → 10s → 20s) pour gérer gracieusement les surcharges temporaires de l'API et éviter les dépassements de limites de débit côté client.

Utiliser le CDN pour les actifs statiquesBien que l'API principale de Didit ne puisse pas être mise en cache par les CDN traditionnels, optimisez les actifs statiques de votre application (JS, CSS, images) via un CDN pour réduire les temps de chargement et améliorer la performance perçue.

L'architecture de performance de DiditL'infrastructure de Didit, nativement IA et distribuée globalement, offre intrinsèquement une faible latence et une haute disponibilité, ce qui en fait un choix idéal pour les besoins de vérification d'identité critiques en termes de performance.

Dans le paysage numérique rapide d'aujourd'hui, chaque milliseconde compte. Pour les développeurs qui intègrent des services de vérification d'identité, l'optimisation des appels API pour la vitesse et l'efficacité est primordiale. Bien que les réseaux de diffusion de contenu (CDN) soient souvent associés à la mise en cache d'actifs statiques, il est crucial de comprendre comment interagir au mieux avec les services API, en particulier ceux conçus pour des opérations dynamiques et en temps réel comme la vérification d'identité, pour la performance globale de l'application. Ce guide explore l'optimisation de vos intégrations API Didit, en se concentrant sur la limitation de débit, les modèles d'appels efficaces et la manière dont l'architecture de Didit prend en charge intrinsèquement des performances élevées.

Comprendre les limites de débit de l'API Didit

Didit, comme tout service API robuste, met en œuvre des limites de débit pour assurer la stabilité et une utilisation équitable entre tous les clients. Ces limites sont essentielles pour prévenir les abus et maintenir des performances constantes. Les comprendre et les respecter est la première étape vers des interactions API optimisées.

Didit applique plusieurs niveaux de limitation de débit :

  • Limites globales : Pour les points de terminaison GET généraux, il y a une limite de 300 requêtes par minute par application. De même, les points de terminaison POST, PATCH et DELETE (écriture/suppression) ont également un plafond global de 300 requêtes par minute par application.
  • Limites spécifiques aux points de terminaison : Certaines opérations à fort impact ont des limites plus restrictives. Par exemple, POST /v2/session/ (pour la création de sessions de vérification, impliquant souvent la vérification d'identité ou l'estimation de l'âge de Didit) est limité à 600 requêtes par minute. La récupération des décisions de session (`GET /v2/session//decision/) est limitée à 100 requêtes par minute pour éviter un polling excessif, et la génération de PDF (GET /session//generate-pdf/`) est également plafonnée à 100 requêtes par minute en raison de sa nature gourmande en CPU.

Lorsqu'une limite de débit est dépassée, l'API de Didit répond avec un code d'état 429 Too Many Requests. Il est crucial de noter que ces réponses incluent des en-têtes utiles :

  • X-RateLimit-Limit : Le nombre maximum de requêtes autorisées.
  • X-RateLimit-Remaining : Le nombre de requêtes restantes dans la fenêtre actuelle.
  • X-RateLimit-Reset : L'heure (en secondes epoch) à laquelle la fenêtre de limite de débit actuelle se réinitialise.

En surveillant ces en-têtes, votre application peut se limiter de manière proactive, évitant les erreurs 429 inutiles et assurant un flux opérationnel plus fluide pour des services comme le filtrage AML ou la détection de vivacité de Didit.

Implémenter une limitation et un backoff intelligents côté client

Une gestion efficace des limites de débit côté client est essentielle pour une intégration résiliente. Voici comment procéder :

  1. Surveiller les en-têtes de limite de débit : Implémentez une logique pour lire l'en-tête X-RateLimit-Remaining. Lorsque cette valeur tombe en dessous d'un certain seuil (par exemple, 15 % de X-RateLimit-Limit), votre client doit commencer à ralentir son taux de requêtes.

  2. Backoff exponentiel pour les 429 : C'est une stratégie critique. Si votre application reçoit une réponse 429, elle doit faire une pause avant de réessayer la requête. Au lieu de retenter immédiatement, implémentez un algorithme de backoff exponentiel. Par exemple, attendez 5 secondes, puis 10 secondes, puis 20 secondes, et ainsi de suite. Cela évite de surcharger davantage l'API et permet à la fenêtre de limite de débit de se réinitialiser. L'en-tête Retry-After de Didit peut également éclairer votre stratégie de backoff.

  3. Journalisation et alertes : Suivez les moments où les limites de débit sont atteintes et quand les tentatives sont déclenchées. Cela fournit des informations précieuses sur les modèles d'utilisation de votre application et peut aider à identifier les domaines d'optimisation ou indiquer la nécessité de demander une limite plus élevée au support Didit pour des cas d'utilisation spécifiques.

Le rôle du Edge Caching CDN dans la performance API

Bien que les API principales de vérification d'identité de Didit, telles que celles pour la vérification d'identité, la correspondance faciale 1:1 ou la vérification NFC, impliquent un traitement dynamique et en temps réel qui ne peut pas être efficacement mis en cache par un CDN (chaque requête étant unique et nécessitant un nouveau calcul), les CDN jouent toujours un rôle dans la performance globale de votre application.

Les CDN excellent dans la mise en cache de contenu statique (images, fichiers JavaScript, CSS, vidéos) à des emplacements périphériques plus proches de vos utilisateurs. En servant ces actifs à partir d'un CDN, vous réduisez la charge sur votre serveur d'origine et diminuez la latence pour vos utilisateurs. Cela améliore la performance perçue de votre application, rendant l'expérience globale, y compris le flux de vérification d'identité, beaucoup plus rapide et plus réactive.

Par exemple, si votre application utilise un flux de travail Didit qui implique une interface utilisateur Web (par exemple, pour la collecte de documents ou les selfies de détection de vivacité), les actifs statiques de cette interface utilisateur peuvent être servis via un CDN. Bien que les appels API vers le backend de Didit pour le traitement de la vérification soient directs, la vitesse de l'environnement d'application environnant a un impact significatif sur la satisfaction de l'utilisateur.

L'architecture IA native de Didit pour des performances inégalées

Didit est construit de A à Z comme une plateforme d'identité nativement IA et axée sur les développeurs. Ce choix architectural offre intrinsèquement des avantages significatifs en termes de performances qui complètent vos stratégies CDN pour les actifs statiques :

  • Distribution globale : L'infrastructure de Didit est distribuée globalement, garantissant une faible latence pour les utilisateurs, quel que soit leur emplacement géographique. Cela signifie que les appels API vers les points de terminaison de vérification de Didit sont acheminés vers le centre de données le plus proche, minimisant le temps de trajet réseau.
  • Optimisé pour le temps réel : Des produits comme la détection de vivacité passive et active et la correspondance faciale 1:1 sont conçus pour le traitement en temps réel, tirant parti de modèles d'IA avancés qui s'exécutent rapidement et efficacement.
  • Évolutivité : L'architecture modulaire de Didit est conçue pour l'évolutivité, capable de gérer de gros volumes de requêtes de vérification sans dégradation des performances, même pendant les périodes de pointe. C'est crucial pour les applications nécessitant un débit élevé pour des services comme la vérification de téléphone et d'e-mail ou la preuve d'adresse.
  • API axées sur les développeurs : Des API claires et bien documentées garantissent que les développeurs peuvent s'intégrer efficacement, réduisant le temps de développement et le potentiel de goulots d'étranglement de performance liés à l'intégration. Le processus d'enregistrement programmatique, ne nécessitant que deux appels API, illustre cette approche axée sur les développeurs.

En vous concentrant sur des pratiques de consommation d'API efficaces, telles que la gestion intelligente des limites de débit et le backoff exponentiel, vous pouvez tirer pleinement parti du backend haute performance et natif IA de Didit pour offrir une expérience de vérification d'identité transparente et rapide.

Comment Didit aide

Didit est conçu pour offrir une expérience de vérification d'identité fiable et performante. Notre plateforme native IA propose une architecture modulaire, vous permettant d'intégrer des primitives d'identité spécifiques comme la vérification d'identité (avec prise en charge OCR, MRZ et code-barres), la détection de vivacité passive et active, la correspondance faciale 1:1 et le filtrage et la surveillance AML selon vos besoins. Cette modularité signifie que vous n'utilisez que les ressources dont vous avez besoin, optimisant à la fois les coûts et les performances. L'offre KYC Core gratuite de Didit, sans frais d'installation et avec un modèle de paiement par vérification réussie, la rend incroyablement accessible pour démarrer. Notre infrastructure distribuée globalement garantit que vos appels API bénéficient d'une faible latence et d'une haute disponibilité, rendant moins pertinente la nécessité d'une mise en cache CDN traditionnelle des réponses API, car la nature dynamique de la vérification d'identité exige un traitement en temps réel. Nous donnons aux développeurs une solution robuste et évolutive qui privilégie intrinsèquement la vitesse et l'efficacité, vous permettant de vous concentrer sur la création d'excellentes applications pendant que nous gérons les complexités de la confiance identitaire.

Prêt à commencer ?

Prêt à voir Didit en action ? Obtenez une démo gratuite dès aujourd'hui.

Commencez à vérifier les identités gratuitement avec l'offre gratuite de Didit.

Infrastructure pour l'identité et la fraude.

Une seule API pour le KYC, le KYB, la surveillance des transactions et le screening de portefeuilles. Intégration en 5 minutes.

Demande à une IA de résumer cette page
Optimisation des appels API Didit pour le Edge Caching CDN.