Limites d’API et nouvelles tentatives

Les limites d’API et les nouvelles tentatives font partie du contrat entre client et API. Le client doit distinguer succès, erreur de validation, échec d’authentification, rate limit et erreur serveur temporaire. Le choix entre JSON et XML ne change pas la sémantique HTTP, et les valeurs IPv4/IPv6 doivent être conservées sans hypothèse de longueur IPv4.

Comment traiter la réponse de l’API

Vérifiez Content-Type, le status code, les champs documentés et le quota. Traitez HTTP 429 séparément, respectez Retry-After et utilisez un exponential backoff borné avec jitter. Tenez compte de l’idempotence avant de réessayer. Journalisez request ID, status et latency, jamais les secrets API.

Le détail important

Après HTTP 429, utilisez Retry-After s’il est présent plutôt qu’une pause fixe arbitraire. Limitez le nombre de tentatives et augmentez progressivement le délai. Ne rejouez pas automatiquement une opération susceptible de créer un doublon. Pour une requête réelle et le contrat API actuel, consultez API 2ip.