Erreur HTTP 429 : Too Many Requests

L'erreur HTTP 429 "Too Many Requests" indique que le client a envoyé trop de requêtes dans un laps de temps donné. C'est le mécanisme de rate limiting qui protège les serveurs et APIs contre les abus, les surcharges et les attaques DDoS.

Le rate limiting est une pratique standard pour toutes les APIs publiques. Chaque fournisseur définit ses propres limites (requêtes par seconde, par minute, par heure) et les communique via des headers spécifiques. Respecter ces limites est essentiel pour maintenir l'accès au service.

Pour le monitoring, le 429 peut être problématique si les checks sont trop fréquents. Une bonne stratégie consiste à espacer les vérifications et à implémenter un exponential backoff en cas de 429 pour éviter de saturer davantage l'API.

Causes principales des erreurs 429

L'erreur 429 survient quand les limites de requêtes sont dépassées :

• Trop de requêtes : Votre application envoie plus de requêtes que la limite autorisée (ex: 100 req/min mais vous en envoyez 200).
• Boucle infinie : Un bug dans le code crée une boucle qui envoie des requêtes en continu, épuisant rapidement le quota.
• IP partagée : Plusieurs utilisateurs ou applications partagent la même IP, cumulant les requêtes vers la même limite.
• Quota épuisé : Le quota journalier ou mensuel est atteint. Courant sur les offres gratuites avec limites strictes.

Headers de rate limiting

Les APIs bien conçues incluent des headers pour gérer le rate limiting :

• Retry-After : Nombre de secondes à attendre avant de réessayer. Header standard obligatoire dans la RFC pour les 429.
• X-RateLimit-Limit : Limite maximale de requêtes pour la période (ex: 1000 requêtes par heure).
• X-RateLimit-Remaining : Nombre de requêtes restantes avant d'atteindre la limite. Utile pour le monitoring proactif.
• X-RateLimit-Reset : Timestamp Unix indiquant quand le compteur sera réinitialisé (ex: 1609459200).

Résolution des erreurs 429

Voici les stratégies pour gérer et éviter les erreurs 429 :

• Exponential backoff : Attendez 1s, puis 2s, 4s, 8s... entre les réessais. Évite de saturer l'API pendant sa récupération.
• Respecter Retry-After : Attendez le temps indiqué dans le header Retry-After avant de réessayer la requête.
• Mise en cache : Cachez les réponses quand possible pour réduire le nombre de requêtes à l'API.
• Webhooks : Préférez les webhooks (push) au polling (pull) pour être notifié sans requêtes répétées.

Implémentation exponential backoff

Voici un exemple d'implémentation d'exponential backoff :

// JavaScript - Exponential backoff
async function fetchWithBackoff(url, maxRetries = 5) {
    for (let i = 0; i < maxRetries; i++) {
        const response = await fetch(url);

        if (response.status === 429) {
            const retryAfter = response.headers.get("Retry-After");
            const waitTime = retryAfter
                ? parseInt(retryAfter) * 1000
                : Math.pow(2, i) * 1000; // 1s, 2s, 4s, 8s, 16s

            console.log(`429 reçu, attente ${waitTime}ms`);
            await new Promise(r => setTimeout(r, waitTime));
            continue;
        }

        return response;
    }
    throw new Error("Max retries atteint");
}

L'exponential backoff évite de saturer l'API en espaçant progressivement les réessais. Toujours respecter Retry-After quand présent.

Monitoring et rate limits

Le monitoring doit respecter les rate limits pour ne pas être bloqué :

• Intervalle approprié : Espacez les checks (1-5 minutes généralement). Évitez les vérifications trop fréquentes sur les APIs tierces.
• Whitelist IP : Si possible, faites whitelister les IP de monitoring auprès du fournisseur d'API pour éviter les 429.
• Surveiller les headers : Surveillez X-RateLimit-Remaining pour anticiper les limites avant d'atteindre le 429.
• Alertes appropriées : Configurez des alertes sur 429 mais évitez le spam si le 429 est temporaire et résolu par backoff.

Questions fréquentes sur HTTP 429

Conclusion

L'erreur HTTP 429 Too Many Requests est un mécanisme de protection essentiel pour les APIs. Respecter les limites de rate limiting est crucial pour maintenir l'accès au service et éviter les blocages.

MoniTao utilise des intervalles de vérification configurables pour éviter de déclencher les rate limits. Pour les APIs tierces avec des limites strictes, espacez vos checks et implémentez un backoff approprié dans vos propres applications.

Prêt à dormir sur vos deux oreilles ?

Commencez gratuitement, sans carte bancaire.

Créer mon compte Voir les tarifs