Rate limiting : comprendre et gérer les limites de requêtes.
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.
L'erreur 429 survient quand les limites de requêtes sont dépassées :
Les APIs bien conçues incluent des headers pour gérer le rate limiting :
Voici les stratégies pour gérer et éviter les erreurs 429 :
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.
Le monitoring doit respecter les rate limits pour ne pas être bloqué :
Utilisez des intervalles de vérification raisonnables (1-5 minutes). MoniTao ne génère qu'une requête par check. Pour les APIs strictes, demandez une whitelist des IPs de monitoring.
C'est une stratégie de réessai qui double le temps d'attente après chaque échec (1s, 2s, 4s, 8s...). Cela évite de saturer un service déjà surchargé.
Indirectement oui. Si Googlebot reçoit des 429, votre crawl budget est gaspillé et l'indexation ralentie. Assurez-vous de ne pas bloquer les bots légitimes.
Consultez le header Retry-After de la réponse. Il indique en secondes combien de temps attendre. Sans ce header, utilisez l'exponential backoff.
Souvent oui. Contactez le fournisseur d'API pour expliquer votre cas d'usage. Les offres payantes ont généralement des limites plus élevées.
Utilisez un middleware (express-rate-limit, Django Ratelimit, etc.). Retournez 429 avec Retry-After et les headers X-RateLimit-*. Documentez vos limites.
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.
Commencez gratuitement, sans carte bancaire.