Rate-limiting
Afin de garantir la stabilité, la sécurité et les performances de notre infrastructure, nous appliquons une politique de limitation de débit (rate limiting) sur les appels à notre API.
Objectifs du rate limiting
La limitation de débit vise à :
- Se prémunir des attaques qui exploiteraient votre accès à nos APIs
- Prévenir les abus ou appels excessifs non maîtrisés.
- Assurer une répartition équitable des ressources entre tous les partenaires.
- Protéger notre système contre les effets d'un code défaillant ou de comportements automatisés agressifs.
- Maintenir une haute disponibilité de notre service.
Fonctionnement
Chaque appel à l’API est comptabilisé, et un plafond est appliqué sur une période glissante. En cas de dépassement, les appels excédentaires seront rejetés avec un code d’erreur approprié (429 Too Many Requests).
Plusieurs mécanismes de limitation sont appliqués :
- Un spike arrest pour limiter le nombre de requêtes/secondes
- Un rate-limiting pour limiter le nombre de requêtes/minutes
- Un quota journalier pour limiter le nombre de requête totales par jour
- Des limites spécifiques sur certains endpoints (les endpoints GET /:items/:id ont par exemple des limites spécifiques).
Ces seuils peuvent varier en fonction du type de partenariat, de l’environnement (sandbox vs production), ou d’un usage spécifique validé avec notre équipe.
Réponse en cas de dépassement
Lorsqu’une limite est atteinte, l’API répond avec :
- Code HTTP 429 :
Too Many Requests - les headers suivants
| header | description | exemple |
|---|---|---|
| X-Quota-Limit | Nombre total de requêtes autorisées sur la période (ex : 1000/jour) | 100000000 |
| X-Quota-Remaining | Nombre de requêtes restantes dans le quota | 99667461 |
| X-Quota-Reset | Timestamp de remise à zéro du quota | 1772540857844 |
| X-Rate-Limit-Limit | Nombre max de requêtes autorisées sur la période | 2750 |
| X-Rate-Limit-Remaining | Nombre de requêtes restantes sur la période en cours | 2503 |
| X-Rate-Limit-Reset | Timestamp (epoch) de réinitialisation du compteur | 1772524301105 |
| X-Spike-Arrest-Limit | Nombre max de requêtes autorisées sur la période | 30 |
| X-Spike-Arrest-Reset | Timestamp (epoch) de réinitialisation du compteur | 1772524285295 |
| X-Spike-Arrest-Slice-Period | Fenêtre glissante de temps sur laquelle le spike-arrest est évalué | 100ms |
Bonnes pratiques recommandées
- Mettez en cache les réponses autant que possible pour limiter les appels redondants.
Ceci est notament applicable à tous les endpoints liés à des entités non mouvantes, tels que les référentiels, les informations sur les clubs/network_nodes, etc.
- Utilisez les webhooks pour être prévenus des créations/changements, plutôt que de synchroniser régulièrement les données.
- Adoptez une stratégie de backoff exponentiel en cas de dépassement (
429). - Ne déclenchez pas de boucle de retry automatique sans contrôle de débit.
Vous avez un projet BI / Datalake / Big-data ?
Les APIs ne sont pas la meilleure réponse pour répondre à vos besoins.
Resamania est doté de capacité d'exports spécifiques qui peuvent pleinement répondre à vos besoins : Contacter nous via le formulaire de contact. pour plus d'information.
WARNING
Ne débutez pas un projet BI en vous servant de nos APIs, vous risqueriez d'être limités (soit au passage en production, soit par nos politique de limitation).
Besoin de plus de capacité ?
Si vous avez des cas d’usage légitimes nécessitant des volumes plus importants (ex : synchronisations massives, appels planifiés, etc.), vous pouvez nous contacter pour discuter d’un ajustement personnalisé de vos limites.
Pour toute question sur la limitation de débit ou pour demander une augmentation de quota, vous pouvez contacter notre équipe par email.