Les API sont un excellent moyen pour les applications logicielles de communiquer entre elles. Elles permettent aux applications logicielles d’interagir et de partager des ressources ou des privil\u00e8ges.<\/p>\n
Aujourd’hui, de nombreuses entreprises B2B proposent leurs services via des API qui peuvent \u00eatre utilis\u00e9es par des applications con\u00e7ues dans n’importe quel langage de programmation et n’importe quel framework. Cependant, cela les rend vuln\u00e9rables aux attaques DoS et DDoS et peut \u00e9galement conduire \u00e0 une distribution in\u00e9gale de la bande passante entre les utilisateurs. Pour r\u00e9soudre ces probl\u00e8mes, une technique connue sous le nom de \u00ab API rate limiting \u00bb est mise en \u0153uvre. L’id\u00e9e est simple : vous limitez le nombre de requ\u00eates que les utilisateurs peuvent adresser \u00e0 votre API.<\/p>\n
Dans ce guide, vous apprendrez ce qu’est la limitation du d\u00e9bit de l’API, les diff\u00e9rentes fa\u00e7ons dont elle peut \u00eatre mise en \u0153uvre, ainsi que quelques bonnes pratiques et exemples \u00e0 retenir lors de la mise en place de la limitation du d\u00e9bit de l’API.
\n
En termes simples, la limitation du d\u00e9bit de l’API consiste \u00e0 fixer un seuil ou une limite au nombre de fois qu’une API<\/a> peut \u00eatre consult\u00e9e par ses utilisateurs. Les limites peuvent \u00eatre fix\u00e9es de plusieurs mani\u00e8res.<\/p>\n L’une des fa\u00e7ons de fixer une limite de d\u00e9bit consiste \u00e0 r\u00e9duire le nombre de fois qu’un utilisateur donn\u00e9 peut acc\u00e9der \u00e0 l’API<\/a> dans un laps de temps donn\u00e9. Pour cela, vous pouvez compter le nombre de requ\u00eates effectu\u00e9es \u00e0 l’aide de la m\u00eame cl\u00e9 API ou de la m\u00eame adresse IP ; lorsqu’un seuil est atteint, les requ\u00eates suppl\u00e9mentaires sont limit\u00e9es ou refus\u00e9es.<\/p>\n Dans de nombreux cas, les d\u00e9veloppeurs souhaitent r\u00e9partir la bande passante disponible pour leur API de mani\u00e8re \u00e9gale entre certains emplacements g\u00e9ographiques.<\/p>\n Le r\u00e9cent service de pr\u00e9visualisation ChatGPT<\/a> est un bon exemple de limitation de d\u00e9bit bas\u00e9e sur la localisation<\/a>, car il a commenc\u00e9 \u00e0 limiter les requ\u00eates en fonction de la localisation des utilisateurs sur la version gratuite du service, une fois que la version payante a \u00e9t\u00e9 d\u00e9ploy\u00e9e. C’\u00e9tait logique puisque la version gratuite \u00e9tait cens\u00e9e \u00eatre utilis\u00e9e par des personnes du monde entier afin de g\u00e9n\u00e9rer un bon \u00e9chantillon de donn\u00e9es d’utilisation pour le service.<\/p>\n La limitation de d\u00e9bit bas\u00e9e sur le serveur est une limite de d\u00e9bit interne mise en \u0153uvre du c\u00f4t\u00e9 du serveur pour assurer une distribution \u00e9quitable des ressources du serveur telles que l’unit\u00e9 centrale, la m\u00e9moire, l’espace disque, etc. Il s’agit de mettre en place une limite sur chaque serveur d’un d\u00e9ploiement.<\/p>\n Lorsqu’un serveur atteint sa limite, les autres requ\u00eates entrantes sont achemin\u00e9es vers un autre serveur disposant d’une capacit\u00e9 disponible. Si tous les serveurs ont atteint leur capacit\u00e9, l’utilisateur re\u00e7oit une r\u00e9ponse 429 Too Many Requests<\/a>. Il est important de noter que les limites de d\u00e9bit bas\u00e9es sur les serveurs sont appliqu\u00e9es \u00e0 tous les clients, ind\u00e9pendamment de leur situation g\u00e9ographique, de l’heure d’acc\u00e8s ou d’autres facteurs.<\/p>\n\n Outre la nature de la mise en \u0153uvre des limites de d\u00e9bit, vous pouvez \u00e9galement classer les limites de d\u00e9bit en fonction de leur effet sur l’utilisateur final. Voici quelques types courants :<\/p>\n Il existe de nombreuses raisons pour lesquelles vous devez mettre en place une limitation de d\u00e9bit dans vos API web<\/a>. Voici quelques-unes des principales raisons :<\/p>\n La premi\u00e8re raison pour laquelle vous devriez envisager de mettre en place une limite de d\u00e9bit dans votre application est de prot\u00e9ger vos ressources contre la surexploitation par des utilisateurs mal intentionn\u00e9s. Les attaquants peuvent utiliser des techniques telles que les attaques DDoS<\/a> pour monopoliser l’acc\u00e8s \u00e0 vos ressources et emp\u00eacher votre application de fonctionner normalement pour les autres utilisateurs. La mise en place d’une limite de d\u00e9bit permet de s’assurer que vous ne facilitez pas la t\u00e2che des attaquants qui veulent perturber vos API.<\/p>\n Outre la protection de vos ressources, la limite de d\u00e9bit vous permet de r\u00e9partir les ressources de votre API entre les utilisateurs. Cela signifie que vous pouvez cr\u00e9er des mod\u00e8les de tarification \u00e9chelonn\u00e9s et r\u00e9pondre aux besoins dynamiques de vos clients sans que cela n’affecte les autres clients.<\/p>\n La limitation des d\u00e9bits \u00e9quivaut \u00e9galement \u00e0 la limitation des co\u00fbts. Cela signifie que vous pouvez r\u00e9partir judicieusement vos ressources entre vos utilisateurs. Avec une structure partitionn\u00e9e, il est plus facile d’estimer les co\u00fbts n\u00e9cessaires \u00e0 l’entretien du syst\u00e8me. Les \u00e9ventuels pics peuvent \u00eatre g\u00e9r\u00e9s intelligemment en provisionnant ou en d\u00e9classant la quantit\u00e9 ad\u00e9quate de ressources.<\/p>\n De nombreuses API reposent sur une architecture distribu\u00e9e qui utilise plusieurs workers\/threads\/instances pour traiter les requ\u00eates entrantes. Dans une telle structure, vous pouvez utiliser des limites de d\u00e9bit pour contr\u00f4ler la charge de travail transmise \u00e0 chaque n\u0153ud de travail. Vous pouvez ainsi vous assurer que les n\u0153uds de travail re\u00e7oivent des charges de travail \u00e9quitables et durables. Vous pouvez facilement ajouter ou supprimer des workers en fonction des besoins sans avoir \u00e0 restructurer l’ensemble de la passerelle API.<\/p>\n Un autre moyen courant de contr\u00f4ler l’utilisation de l’API consiste \u00e0 d\u00e9finir une limite de rafale (\u00e9galement appel\u00e9e \u00ab throttling \u00bb) au lieu d’une limite de d\u00e9bit. Les limites de rafale sont des limites de d\u00e9bit mises en \u0153uvre pour un tr\u00e8s petit intervalle de temps, par exemple quelques secondes. Par exemple, au lieu de fixer une limite de 1,3 million de requ\u00eates par mois, vous pouvez fixer une limite de 5 requ\u00eates par seconde. Bien que cela \u00e9quivaille au m\u00eame trafic mensuel, cela garantit que vos clients ne surchargent pas vos serveurs en envoyant des rafales de milliers de requ\u00eates \u00e0 la fois.<\/p>\n Dans le cas des limites de rafales, les requ\u00eates sont souvent retard\u00e9es jusqu’au prochain intervalle au lieu d’\u00eatre refus\u00e9es. Il est \u00e9galement souvent recommand\u00e9 d’utiliser \u00e0 la fois les limites de d\u00e9bit et les limites de rafale pour un contr\u00f4le optimal du trafic et de l’utilisation.<\/p>\n En ce qui concerne la mise en \u0153uvre, il existe quelques m\u00e9thodes que vous pouvez utiliser pour mettre en place une limitation de d\u00e9bit de l’API dans votre application. Ces m\u00e9thodes sont les suivantes :<\/p>\n L’une des m\u00e9thodes pratiques les plus simples pour limiter l’acc\u00e8s \u00e0 l’API consiste \u00e0 utiliser des files d’attente de requ\u00eates. Les files d’attente de requ\u00eates font r\u00e9f\u00e9rence \u00e0 un m\u00e9canisme dans lequel les requ\u00eates entrantes sont stock\u00e9es sous la forme d’une file d’attente et trait\u00e9es l’une apr\u00e8s l’autre jusqu’\u00e0 une certaine limite.<\/p>\n Un cas d’utilisation courant des files d’attente est la s\u00e9paration des requ\u00eates entrantes des utilisateurs gratuits et payants. Voici comment vous pouvez le faire dans une application Express<\/a> \u00e0 l’aide du paquetage Le throttling est une autre technique utilis\u00e9e pour contr\u00f4ler l’acc\u00e8s aux API. Au lieu de couper l’acc\u00e8s lorsqu’un seuil est atteint, il se concentre sur l’att\u00e9nuation des pics de trafic de l’API en mettant en \u0153uvre de petits seuils pour de petites plages de temps. Au lieu d’\u00e9tablir une limite de taux comme 3 millions d’appels par mois, le throttling \u00e9tablit des limites de 10 appels par seconde. D\u00e8s qu’un client envoie plus de 10 appels en une seconde, les requ\u00eates suivantes dans la m\u00eame seconde sont automatiquement limit\u00e9es, mais le client retrouve instantan\u00e9ment l’acc\u00e8s \u00e0 l’API dans la seconde suivante.<\/p>\n Vous pouvez le mettre en \u0153uvre dans Express \u00e0 l’aide du paquetage Vous pouvez tester l’application \u00e0 l’aide d’un outil de test de charge comme AutoCannon<\/a>. Vous pouvez installer AutoCannon en ex\u00e9cutant la commande suivante dans votre terminal :<\/p>\n Vous pouvez tester l’application en utilisant ce qui suit :<\/p>\n Le test utilise 10 connexions simultan\u00e9es qui envoient des requ\u00eates \u00e0 l’API. Voici le r\u00e9sultat du test :<\/p>\n \u00c9tant donn\u00e9 que seules 10 requ\u00eates par seconde \u00e9taient autoris\u00e9es (avec une rafale suppl\u00e9mentaire de 5 requ\u00eates), seules 114 requ\u00eates ont \u00e9t\u00e9 trait\u00e9es par l’API, et les requ\u00eates restantes ont re\u00e7u un code d’erreur 503 demandant d’attendre un certain temps.<\/p>\n Bien que la limitation de d\u00e9bit semble \u00eatre un concept simple qui peut \u00eatre mis en \u0153uvre \u00e0 l’aide d’une file d’attente, elle peut, en fait, \u00eatre mise en \u0153uvre de diff\u00e9rentes mani\u00e8res offrant divers avantages. Voici quelques algorithmes populaires utilis\u00e9s pour mettre en \u0153uvre la limitation de d\u00e9bit :<\/p>\n L’algorithme \u00e0 fen\u00eatre fixe est l’un des algorithmes de limitation de d\u00e9bit les plus simples. Il limite le nombre de requ\u00eates pouvant \u00eatre trait\u00e9es dans un intervalle de temps fixe.<\/p>\n Vous d\u00e9finissez un nombre fixe de requ\u00eates, disons 100, qui peuvent \u00eatre trait\u00e9es par le serveur API en une heure. Lorsque la 101\u00e8me requ\u00eate arrive, l’algorithme refuse de la traiter. Lorsque l’intervalle de temps est r\u00e9initialis\u00e9 (c’est-\u00e0-dire dans l’heure suivante), 100 autres requ\u00eates entrantes peuvent \u00eatre trait\u00e9es.<\/p>\n Cet algorithme est simple \u00e0 mettre en \u0153uvre et fonctionne bien dans de nombreux cas o\u00f9 la limitation du d\u00e9bit c\u00f4t\u00e9 serveur est n\u00e9cessaire pour contr\u00f4ler la bande passante (contrairement \u00e0 la r\u00e9partition de la bande passante entre les utilisateurs). Cependant, il peut entra\u00eener un trafic\/traitement irr\u00e9gulier vers les limites de l’intervalle de temps fix\u00e9. L’algorithme de la fen\u00eatre coulissante est une meilleure alternative dans les cas o\u00f9 vous avez besoin d’un traitement r\u00e9gulier.<\/p>\n L’algorithme \u00e0 fen\u00eatre glissante est une variante de l’algorithme de la fen\u00eatre fixe. Au lieu d’utiliser des intervalles de temps fixes pr\u00e9d\u00e9finis, cet algorithme utilise une fen\u00eatre temporelle mobile pour suivre le nombre de requ\u00eates trait\u00e9es et entrantes.<\/p>\n Au lieu d’examiner les intervalles de temps absolus (de 60 secondes chacun, par exemple), tels que 0s \u00e0 60s, 61s \u00e0 120s, et ainsi de suite, l’algorithme \u00e0 fen\u00eatre glissante examine les 60s pr\u00e9c\u00e9dentes \u00e0 partir du moment o\u00f9 une requ\u00eate est re\u00e7ue. Supposons qu’une requ\u00eate soit re\u00e7ue \u00e0 la 82\u00e8me seconde ; l’algorithme comptera alors le nombre de requ\u00eates trait\u00e9es entre 22 et 82 secondes (au lieu de l’intervalle absolu de 60 \u00e0 120 secondes) pour d\u00e9terminer si cette requ\u00eate peut \u00eatre trait\u00e9e ou non. Cela permet d’\u00e9viter les situations dans lesquelles un grand nombre de requ\u00eates est trait\u00e9 \u00e0 la fois \u00e0 la 59\u00e8me et \u00e0 la 61\u00e8me seconde, ce qui surcharge le serveur pendant une tr\u00e8s courte p\u00e9riode.<\/p>\n Cet algorithme permet de g\u00e9rer plus facilement le trafic en rafale, mais il peut \u00eatre plus difficile \u00e0 mettre en \u0153uvre et \u00e0 maintenir que l’algorithme \u00e0 fen\u00eatre fixe.<\/p>\n Dans cet algorithme, un seau fictif est rempli de jetons, et chaque fois que le serveur traite une requ\u00eate, un jeton est retir\u00e9 du seau. Lorsque le seau est vide, le serveur ne peut plus traiter de requ\u00eates. Les autres requ\u00eates sont retard\u00e9es ou refus\u00e9es jusqu’\u00e0 ce que le seau soit \u00e0 nouveau rempli.<\/p>\n Le seau de jetons est rempli \u00e0 un rythme fixe (appel\u00e9 taux de g\u00e9n\u00e9ration de jetons) et le nombre maximal de jetons pouvant \u00eatre stock\u00e9s dans le seau est \u00e9galement fixe (appel\u00e9 profondeur du seau).<\/p>\n En contr\u00f4lant le taux de r\u00e9g\u00e9n\u00e9ration des jetons et la profondeur du seau, vous pouvez contr\u00f4ler le d\u00e9bit maximal de trafic autoris\u00e9 par l’API. Le paquet Le principal avantage de cet algorithme est qu’il prend en charge le trafic en rafale tant qu’il peut \u00eatre pris en compte dans la profondeur du seau. Ceci est particuli\u00e8rement utile pour le trafic impr\u00e9visible.<\/p>\n L’algorithme du seau perc\u00e9 est un autre algorithme permettant de g\u00e9rer le trafic des API. Au lieu de maintenir une profondeur de seau qui d\u00e9termine le nombre de requ\u00eates pouvant \u00eatre trait\u00e9es dans un laps de temps donn\u00e9 (comme dans un seau de jetons), il autorise un flux fixe de requ\u00eates \u00e0 partir du seau, ce qui est analogue \u00e0 l’\u00e9coulement r\u00e9gulier de l’eau \u00e0 partir d’un seau qui fuit.<\/p>\n Dans ce cas, la profondeur du seau est utilis\u00e9e pour d\u00e9terminer le nombre de requ\u00eates qui peuvent \u00eatre mises en file d’attente avant que le seau ne commence \u00e0 d\u00e9border, c’est-\u00e0-dire \u00e0 refuser les requ\u00eates entrantes.<\/p>\n Le seau perc\u00e9 promet un flux r\u00e9gulier de requ\u00eates et, contrairement au seau de jetons, ne g\u00e8re pas les pics de trafic.<\/p>\n Maintenant que vous savez ce qu’est la limitation de d\u00e9bit de l’API et comment elle est mise en \u0153uvre, voici quelques bonnes pratiques \u00e0 adopter. Voici quelques bonnes pratiques \u00e0 prendre en compte lors de sa mise en \u0153uvre dans votre application.<\/p>\n Lorsque vous envisagez de mettre en place une limite de d\u00e9bit de l’API, essayez toujours de proposer un niveau gratuit ad\u00e9quat que vos utilisateurs potentiels peuvent utiliser pour essayer votre API. Il n’est pas n\u00e9cessaire d’\u00eatre tr\u00e8s g\u00e9n\u00e9reux, mais cela doit \u00eatre suffisant pour leur permettre de tester confortablement votre API dans leur application de d\u00e9veloppement.<\/p>\n Bien que les limites de d\u00e9bit de l’API soient essentielles au maintien de la qualit\u00e9 de vos points de terminaison d’API pour vos utilisateurs, un petit niveau gratuit non limit\u00e9 peut vous aider \u00e0 gagner de nouveaux utilisateurs.<\/p>\n Lorsqu’un utilisateur d\u00e9passe la limite de d\u00e9bit de votre API, vous devez prendre certaines mesures pour garantir une exp\u00e9rience positive \u00e0 l’utilisateur tout en prot\u00e9geant vos ressources. Voici quelques-unes des questions que vous devez poser et des consid\u00e9rations que vous devez prendre en compte :<\/p>\n La premi\u00e8re chose \u00e0 faire est d’informer vos utilisateurs qu’ils ont d\u00e9pass\u00e9 la limite fix\u00e9e pour le d\u00e9bit de l’API. Pour ce faire, vous devez remplacer la r\u00e9ponse de l’API par un message pr\u00e9d\u00e9fini qui explique le probl\u00e8me. Il est important que le code d’\u00e9tat de cette r\u00e9ponse soit 429 \u00ab\u00a0oo Many Requests<\/i> Il est \u00e9galement d’usage d’expliquer le probl\u00e8me dans le corps de la r\u00e9ponse. Voici un exemple de corps de r\u00e9ponse :<\/p>\n L’exemple de corps de r\u00e9ponse ci-dessus mentionne le nom et la description de l’erreur et sp\u00e9cifie \u00e9galement une dur\u00e9e (g\u00e9n\u00e9ralement en secondes) apr\u00e8s laquelle l’utilisateur peut r\u00e9essayer d’envoyer des requ\u00eates. Un corps de r\u00e9ponse descriptif comme celui-ci aide les utilisateurs \u00e0 comprendre ce qui s’est pass\u00e9 et pourquoi ils n’ont pas re\u00e7u la r\u00e9ponse qu’ils attendaient. Il leur permet \u00e9galement de savoir combien de temps ils doivent attendre avant d’envoyer une autre requ\u00eate.<\/p>\n Un autre point de d\u00e9cision est de savoir ce qu’il faut faire lorsque la limite de d\u00e9bit de l’API est d\u00e9pass\u00e9e par un utilisateur. En g\u00e9n\u00e9ral, vous emp\u00eachez l’utilisateur d’interagir avec le serveur en renvoyant une r\u00e9ponse 429 Too Many Requests, comme vous l’avez vu ci-dessus. Cependant, vous devriez \u00e9galement envisager une autre approche : le throttling.<\/p>\n Au lieu de couper compl\u00e8tement l’acc\u00e8s aux ressources du serveur, vous pouvez ralentir le nombre total de requ\u00eates que l’utilisateur peut envoyer dans un certain laps de temps. Cette m\u00e9thode est utile lorsque vous souhaitez donner une petite tape sur les doigts \u00e0 vos utilisateurs tout en leur permettant de continuer \u00e0 travailler s’ils r\u00e9duisent leur volume de requ\u00eates.<\/p>\n Les limites de d\u00e9bit des API sont d\u00e9sagr\u00e9ables : elles emp\u00eachent vos utilisateurs d’interagir avec vos services API et de les utiliser. C’est particuli\u00e8rement grave pour les utilisateurs qui doivent effectuer des requ\u00eates similaires \u00e0 plusieurs reprises, comme l’acc\u00e8s \u00e0 un ensemble de donn\u00e9es de pr\u00e9visions m\u00e9t\u00e9orologiques qui n’est mis \u00e0 jour qu’une fois par semaine ou la r\u00e9cup\u00e9ration d’une liste d’options pour un menu d\u00e9roulant qui pourrait \u00eatre modifi\u00e9 une fois par semaine. Dans ces cas, une approche intelligente consisterait \u00e0 mettre en place un syst\u00e8me de cache.<\/p>\n La mise en cache<\/a> est une abstraction de stockage \u00e0 grande vitesse mise en \u0153uvre dans les cas o\u00f9 le volume d’acc\u00e8s aux donn\u00e9es est \u00e9lev\u00e9, mais o\u00f9 les donn\u00e9es ne changent pas tr\u00e8s souvent. Au lieu d’effectuer un appel d’API susceptible d’invoquer plusieurs services internes et d’entra\u00eener de lourdes d\u00e9penses, vous pourriez mettre en cache les points de terminaison les plus fr\u00e9quemment utilis\u00e9s, de sorte que la deuxi\u00e8me requ\u00eate soit servie \u00e0 partir du cache statique, ce qui est g\u00e9n\u00e9ralement plus rapide, moins co\u00fbteux et peut r\u00e9duire la charge de travail de vos services principaux.<\/p>\n Il peut \u00e9galement arriver que vous receviez un nombre anormalement \u00e9lev\u00e9 de requ\u00eates de la part d’un utilisateur. M\u00eame apr\u00e8s avoir fix\u00e9 une limite de d\u00e9bit, ils atteignent constamment leur capacit\u00e9 et sont limit\u00e9s dans leur d\u00e9bit. Ce type de situation indique qu’il existe un risque d’abus de l’API.<\/p>\n Pour prot\u00e9ger vos services de la surcharge et maintenir une exp\u00e9rience uniforme pour le reste de vos utilisateurs, vous devez envisager de restreindre compl\u00e8tement l’acc\u00e8s de l’utilisateur suspect \u00e0 l’API. C’est ce qu’on appelle la coupure de circuit, et bien qu’elle semble similaire \u00e0 la limitation de d\u00e9bit, elle est g\u00e9n\u00e9ralement utilis\u00e9e lorsque le syst\u00e8me est confront\u00e9 \u00e0 une surcharge de requ\u00eates et a besoin de temps pour ralentir afin de retrouver sa qualit\u00e9 de service.<\/p>\n Bien que les limites de d\u00e9bit des API soient destin\u00e9es \u00e0 r\u00e9partir \u00e9quitablement vos ressources entre vos utilisateurs, elles peuvent parfois causer des probl\u00e8mes inutiles \u00e0 vos utilisateurs ou m\u00eame indiquer une activit\u00e9 suspecte.<\/p>\n La mise en place d’une solution de surveillance robuste<\/a> pour votre API peut vous aider \u00e0 comprendre \u00e0 quelle fr\u00e9quence les limites de taux sont atteintes par vos utilisateurs, si vous devez ou non reconsid\u00e9rer les limites g\u00e9n\u00e9rales tout en gardant \u00e0 l’esprit la charge de travail moyenne de vos utilisateurs et identifier les utilisateurs qui atteignent fr\u00e9quemment leurs limites (ce qui pourrait indiquer qu’ils ont besoin d’une augmentation prochaine de leurs limites ou qu’ils doivent \u00eatre surveill\u00e9s pour toute activit\u00e9 suspecte). Dans tous les cas, une configuration de surveillance active vous aidera \u00e0 mieux comprendre l’impact des limites de d\u00e9bit de votre API.<\/p>\n La limitation de d\u00e9bit peut \u00eatre mise en \u0153uvre \u00e0 plusieurs niveaux (utilisateur, application ou syst\u00e8me). De nombreuses personnes commettent l’erreur de d\u00e9finir des limites de d\u00e9bit \u00e0 un seul de ces niveaux et de s’attendre \u00e0 ce qu’elles couvrent tous les cas possibles. Bien qu’il ne s’agisse pas exactement d’un anti-mod\u00e8le, cela peut s’av\u00e9rer inefficace dans certains cas.<\/p>\n Si les requ\u00eates entrantes surchargent l’interface r\u00e9seau de votre syst\u00e8me, votre limitation de d\u00e9bit au niveau de l’application risque de ne m\u00eame pas pouvoir optimiser les charges de travail. Il est donc pr\u00e9f\u00e9rable de d\u00e9finir les r\u00e8gles de limitation de d\u00e9bit \u00e0 plusieurs niveaux, de pr\u00e9f\u00e9rence dans les couches sup\u00e9rieures de votre architecture, afin d’\u00e9viter la cr\u00e9ation de goulets d’\u00e9tranglement.<\/p>\n Dans cette section, vous apprendrez \u00e0 tester les limites de d\u00e9bit de l’API pour un point de terminaison API donn\u00e9 et \u00e0 mettre en \u0153uvre un contr\u00f4le de l’utilisation sur votre client afin de vous assurer que vous ne finirez pas par \u00e9puiser les limites de votre API distante.<\/p>\n Pour identifier la limite de d\u00e9bit d’une API, votre premi\u00e8re approche doit toujours \u00eatre de lire la documentation de l’API afin de d\u00e9terminer si les limites ont \u00e9t\u00e9 clairement d\u00e9finies. Dans la plupart des cas, la documentation de l’API vous indiquera la limite et la mani\u00e8re dont elle a \u00e9t\u00e9 mise en \u0153uvre. Vous ne devez recourir au \u00ab test \u00bb de la limite de taux de l’API pour l’identifier que si vous ne pouvez pas l’identifier \u00e0 partir de la documentation de l’API, de l’assistance ou de la communaut\u00e9. En effet, tester une API pour trouver sa limite de d\u00e9bit signifie que vous finirez par \u00e9puiser votre limite de d\u00e9bit au moins une fois, ce qui peut entra\u00eener des co\u00fbts financiers et\/ou l’indisponibilit\u00e9 de l’API pendant une certaine dur\u00e9e.<\/p>\n Si vous cherchez \u00e0 identifier manuellement la limite de d\u00e9bit, commencez par utiliser un outil de test d’API simple comme Postman pour effectuer des requ\u00eates manuellement \u00e0 l’API et voir si vous pouvez \u00e9puiser sa limite de d\u00e9bit. Si ce n’est pas le cas, vous pouvez alors utiliser un outil de test de charge comme Autocannon ou Gatling pour simuler un grand nombre de requ\u00eates et voir combien de requ\u00eates sont trait\u00e9es par l’API avant qu’elle ne commence \u00e0 r\u00e9pondre avec un code d’\u00e9tat 429.<\/p>\n Une autre approche peut consister \u00e0 utiliser un outil de v\u00e9rification des limites de d\u00e9bit tel que celui d’AppBrokers Toutefois, si vous n’\u00eates pas s\u00fbr de la limite de d\u00e9bit d’une API, vous pouvez toujours essayer d’estimer vos besoins en termes de requ\u00eates et de d\u00e9finir des limites c\u00f4t\u00e9 client afin de vous assurer que le nombre de requ\u00eates de votre application ne d\u00e9passe pas ce chiffre. Vous apprendrez comment proc\u00e9der dans la section suivante.<\/p>\n Si vous faites des appels \u00e0 une API \u00e0 partir de votre code, vous voudrez peut-\u00eatre mettre en place un syst\u00e8me de throttling de votre c\u00f4t\u00e9 pour vous assurer que vous ne faites pas accidentellement trop d’appels \u00e0 l’API et que vous n’\u00e9puisez pas votre limite d’API. Il existe plusieurs fa\u00e7ons de proc\u00e9der. L’une des plus courantes consiste \u00e0 utiliser la m\u00e9thode throttle de la biblioth\u00e8que utilitaire lodash.<\/p>\n Avant de commencer \u00e0 limiter les appels \u00e0 l’API, vous devez cr\u00e9er une API. Voici un exemple de code pour une API bas\u00e9e sur Node.js qui imprime dans la console le nombre moyen de requ\u00eates qu’elle re\u00e7oit par minute :<\/p>\n Une fois cette application ex\u00e9cut\u00e9e, elle affichera le nombre moyen de requ\u00eates re\u00e7ues chaque seconde :<\/p>\n Ensuite, cr\u00e9ez un nouveau fichier JavaScript appel\u00e9 test-throttle.js<\/b> et enregistrez-y le code suivant :<\/p>\n Une fois que vous aurez ex\u00e9cut\u00e9 ce script, vous remarquerez que le nombre moyen de requ\u00eates pour le serveur s’\u00e9l\u00e8ve \u00e0 pr\u00e8s de 10 :<\/p>\n Que se passerait-il si cette API n’autorisait que 6 requ\u00eates par seconde, par exemple ? Vous souhaiteriez maintenir votre nombre moyen de requ\u00eates en dessous de ce chiffre. Toutefois, si votre client envoie une requ\u00eate en fonction d’une activit\u00e9 de l’utilisateur, comme le clic d’un bouton ou un d\u00e9filement, il se peut que vous ne puissiez pas limiter le nombre de fois o\u00f9 l’appel \u00e0 l’API est d\u00e9clench\u00e9.<\/p>\n La fonction Ensuite, mettez \u00e0 jour le fichier test-throttle.js<\/b> pour qu’il contienne le code suivant :<\/p>\n Maintenant, si vous regardez les journaux du serveur, vous verrez une sortie similaire :<\/p>\n Cela signifie que m\u00eame si votre application appelle la fonction Lorsque vous travaillez avec des API \u00e0 d\u00e9bit limit\u00e9, vous pouvez rencontrer diverses r\u00e9ponses indiquant qu’une limite de d\u00e9bit a \u00e9t\u00e9 d\u00e9pass\u00e9e. Dans la plupart des cas, vous recevrez le code d’\u00e9tat 429 accompagn\u00e9 d’un message similaire \u00e0 l’un des suivants :<\/p>\n Toutefois, le message que vous recevez d\u00e9pend de l’impl\u00e9mentation de l’API que vous utilisez. Cette impl\u00e9mentation peut varier, et certaines API peuvent m\u00eame ne pas utiliser le code d’\u00e9tat 429. Voici d’autres types de codes d’erreur et de messages relatifs \u00e0 la limite de d\u00e9bit que vous pouvez recevoir lorsque vous travaillez avec des API \u00e0 d\u00e9bit limit\u00e9 :<\/p>\n Lorsque vous d\u00e9finissez la limite de d\u00e9bit de votre API, il peut \u00eatre utile d’examiner la mani\u00e8re dont certains des principaux fournisseurs d’API proc\u00e8dent :<\/p>\n Lorsque vous cr\u00e9ez des API, il est essentiel d’assurer un contr\u00f4le optimal du trafic. Si vous ne surveillez pas de pr\u00e8s la gestion de votre trafic, vous vous retrouverez rapidement avec une API surcharg\u00e9e et non fonctionnelle. Inversement, lorsque vous travaillez avec une API \u00e0 d\u00e9bit limit\u00e9, il est important de comprendre comment fonctionne la limitation du d\u00e9bit et comment vous devez utiliser l’API pour garantir une disponibilit\u00e9 et une utilisation maximales.<\/p>\n Dans ce guide, vous avez appris ce qu’est la limitation de d\u00e9bit de l’API, pourquoi elle est n\u00e9cessaire, comment elle peut \u00eatre mise en \u0153uvre et quelques bonnes pratiques que vous devez garder \u00e0 l’esprit lorsque vous travaillez avec des limites de d\u00e9bit de l’API.<\/p>\n D\u00e9couvrez l’h\u00e9bergement d’applications<\/a> de Kinsta et lancez votre prochain projet Node.js<\/a> d\u00e8s aujourd’hui !<\/p>\n Vous travaillez avec une API \u00e0 d\u00e9bit limit\u00e9 ? Ou vous avez mis en place une limitation de d\u00e9bit dans votre propre API ? Faites-nous en part dans les commentaires ci-dessous !<\/i><\/p>\n","protected":false},"excerpt":{"rendered":" Les API sont un excellent moyen pour les applications logicielles de communiquer entre elles. Elles permettent aux applications logicielles d’interagir et de partager des ressources ou …<\/p>\n","protected":false},"author":199,"featured_media":70480,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kinsta_gated_content":false,"_kinsta_gated_content_redirect":"","footnotes":""},"tags":[],"topic":[953],"class_list":["post-70479","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","topic-api"],"yoast_head":"\n1. Limites bas\u00e9es sur l’utilisateur<\/h3>\n
2. Limites bas\u00e9es sur la localisation<\/h3>\n
3. Limites bas\u00e9es sur le serveur<\/h3>\n
Types de limites de d\u00e9bit de l’API<\/h2>\n
\n
Pourquoi est-il n\u00e9cessaire de limiter le d\u00e9bit ?<\/h2>\n
1. Protection de l’acc\u00e8s aux ressources<\/h3>\n
2. R\u00e9partition du quota entre les utilisateurs<\/h3>\n
3. Am\u00e9lioration de la rentabilit\u00e9<\/h3>\n
4. Gestion des flux entre les workers<\/h3>\n
Comprendre les limites de rafale<\/h2>\n
3 M\u00e9thodes de mise en \u0153uvre de la limitation de d\u00e9bit<\/h2>\n
1. Files d’attente de requ\u00eates<\/h3>\n
express-queue<\/code>:<\/p>\nconst express = require('express')\nconst expressQueue = require('express-queue');\n\nconst app = express()\n\nconst freeRequestsQueue = expressQueue({\n activeLimit: 1, \/\/ Maximum requests to process at once\n queuedLimit: -1 \/\/ Maximum requests allowed in queue (-1 means unlimited)\n});\n\nconst paidRequestsQueue = expressQueue({\n activeLimit: 5, \/\/ Maximum requests to process at once\n queuedLimit: -1 \/\/ Maximum requests allowed in queue (-1 means unlimited)\n});\n\n\/\/ Middleware that selects the appropriate queue handler based on the presence of an API token in the request\nfunction queueHandlerMiddleware(req, res, next) {\n \/\/ Check if the request contains an API token\n const apiToken = req.headers['api-token'];\n\n if (apiToken && isValidToken(apiToken)) {\n console.log(\"Paid request received\")\n paidRequestsQueue(req, res, next);\n } else {\n console.log(\"Free request received\")\n freeRequestsQueue(req, res, next);\n }\n}\n\n\/\/ Add the custom middleware function to the route\napp.get('\/route', queueHandlerMiddleware, (req, res) => {\n res.status(200).json({ message: \"Processed!\" })\n});\n\n\/\/ Check here is the API token is valid or not\nconst isValidToken = () => {\n return true;\n}\n\napp.listen(3000);<\/code><\/pre>\n2. Throttling<\/h3>\n
express-throttle<\/code>. Voici un exemple d’application Express qui montre comment configurer le throttling dans votre application :<\/p>\nconst express = require('express')\nconst throttle = require('express-throttle')\n\nconst app = express()\n\nconst throttleOptions = {\n \"rate\": \"10\/s\",\n \"burst\": 5,\n \"on_allowed\": function (req, res, next, bucket) {\n res.set(\"X-Rate-Limit-Limit\", 10);\n res.set(\"X-Rate-Limit-Remaining\", bucket.tokens);\n next()\n },\n \"on_throttled\": function (req, res, next, bucket) {\n \/\/ Notify client\n res.set(\"X-Rate-Limit-Limit\", 10);\n res.set(\"X-Rate-Limit-Remaining\", 0);\n res.status(503).send(\"System overloaded, try again after a few seconds.\");\n }\n}\n\n\/\/ Add the custom middleware function to the route\napp.get('\/route', throttle(throttleOptions), (req, res) => {\n res.status(200).json({ message: \"Processed!\" })\n});\n\napp.listen(3000);<\/code><\/pre>\nnpm install autocannon -g<\/code><\/pre>\nautocannon http:\/\/localhost:3000\/route<\/code><\/pre>\nRunning 10s test @ http:\/\/localhost:3000\/route\n\n10 connections\n\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Stat \u2502 2.5% \u2502 50% \u2502 97.5% \u2502 99% \u2502 Avg \u2502 Stdev \u2502 Max \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 Latency \u2502 0 ms \u2502 0 ms \u2502 1 ms \u2502 1 ms \u2502 0.04 ms \u2502 0.24 ms \u2502 17 ms \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Stat \u2502 1% \u2502 2.5% \u2502 50% \u2502 97.5% \u2502 Avg \u2502 Stdev \u2502 Min \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 Req\/Sec \u2502 16591 \u2502 16591 \u2502 19695 \u2502 19903 \u2502 19144 \u2502 1044.15 \u2502 16587 \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 Bytes\/Sec \u2502 5.73 MB \u2502 5.73 MB \u2502 6.8 MB \u2502 6.86 MB \u2502 6.6 MB \u2502 360 kB \u2502 5.72 MB \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\nReq\/Bytes counts sampled once per second.\n# of samples: 11\n114 2xx responses, 210455 non 2xx responses\n211k requests in 11.01s, 72.6 MB read<\/code><\/pre>\n3. Algorithmes de limitation de d\u00e9bit<\/h3>\n
Algorithme \u00e0 fen\u00eatre fixe<\/h4>\n
Algorithme \u00e0 fen\u00eatre glissante<\/h4>\n
Algorithme du seau de jetons<\/h4>\n
express-throttle<\/code> que vous avez vu pr\u00e9c\u00e9demment utilise l’algorithme du seau de jetons pour limiter ou contr\u00f4ler le flux de trafic de l’API.<\/p>\nAlgorithme du seau perc\u00e9<\/h4>\n
Meilleures pratiques pour la limitation du d\u00e9bit de l’API<\/h2>\n
Proposez un niveau gratuit aux utilisateurs pour qu’ils explorent vos services<\/h3>\n
D\u00e9terminez ce qui se passe en cas de d\u00e9passement de la limite de d\u00e9bit<\/h3>\n
Quel code d’erreur et quel message vos utilisateurs verront-ils ?<\/h4>\n
{\n \"error\": \"Too Many Requests\",\n \"message\": \"You have exceeded the set API rate limit of X requests per minute. Please try again in a few minutes.\",\n \"retry_after\": 60\n}<\/code><\/pre>\nLes nouvelles requ\u00eates seront-elles limit\u00e9es ou compl\u00e8tement arr\u00eat\u00e9es ?<\/h4>\n
Envisagez la mise en cache et la coupure de circuit<\/h3>\n
Surveillez de pr\u00e8s votre configuration<\/h3>\n
Mettez en \u0153uvre la limitation de d\u00e9bit \u00e0 plusieurs niveaux<\/h3>\n
Utilisation des limites de d\u00e9bit de l’API<\/h2>\n
Comment tester les limites de d\u00e9bit de l’API<\/h3>\n
rate-limit-test-tool<\/a><\/code>. Des outils d\u00e9di\u00e9s comme celui-ci automatisent le processus pour vous et vous fournissent \u00e9galement une interface utilisateur pour analyser soigneusement les r\u00e9sultats du test.<\/p>\nComment limiter les appels \u00e0 l’API<\/h3>\n
const express = require('express');\nconst app = express();\n\n\/\/ maintain a count of total requests\nlet requestTotalCount = 0;\nlet startTime = Date.now();\n\n\/\/ increase the count whenever any request is received\napp.use((req, res, next) => {\n requestTotalCount++;\n next();\n});\n\n\/\/ After each second, print the average number of requests received per second since the server was started\nsetInterval(() => {\n const elapsedTime = (Date.now() - startTime) \/ 1000;\n const averageRequestsPerSecond = requestTotalCount \/ elapsedTime;\n console.log(`Average requests per second: ${averageRequestsPerSecond.toFixed(2)}`);\n}, 1000);\n\napp.get('\/', (req, res) => {\n res.send('Hello World!');\n});\n\napp.listen(3000, () => {\n console.log('Server listening on port 3000!');\n});<\/code><\/pre>\nAverage requests per second: 0\nAverage requests per second: 0\nAverage requests per second: 0<\/code><\/pre>\n\/\/ function that calls the API and prints the response\nconst request = () => {\n fetch('http:\/\/localhost:3000')\n .then(r => r.text())\n .then(r => console.log(r))\n}\n\n\/\/ Loop to call the request function once every 100 ms, i.e., 10 times per second\nsetInterval(request, 100)<\/code><\/pre>\nAverage requests per second: 9.87\nAverage requests per second: 9.87\nAverage requests per second: 9.88<\/code><\/pre>\nthrottle()<\/code> de la biblioth\u00e8que lodash<\/code> peut vous aider. Tout d’abord, installez la biblioth\u00e8que en ex\u00e9cutant la commande suivante :<\/p>\nnpm install lodash<\/code><\/pre>\n\/\/ import the lodash library\nconst { throttle } = require('lodash');\n\n\/\/ function that calls the API and prints the response\nconst request = () => {\n fetch('http:\/\/localhost:3000')\n .then(r => r.text())\n .then(r => console.log(r))\n}\n\n\/\/ create a throttled function that can only be called once every 200 ms, i.e., only 5 times every second\nconst throttledRequest = throttle(request, 200)\n\n\/\/ loop this throttled function to be called once every 100 ms, i.e., 10 times every second\nsetInterval(throttledRequest, 100)<\/code><\/pre>\nAverage requests per second: 4.74\nAverage requests per second: 4.80\nAverage requests per second: 4.83\n<\/code><\/pre>\nrequest<\/code> 10 fois par seconde, la fonction de throttling veille \u00e0 ce qu’elle ne soit appel\u00e9e que 5 fois par seconde, ce qui vous permet de rester en dessous de la limite de d\u00e9bit. Voil\u00e0 comment vous pouvez mettre en place un throttling c\u00f4t\u00e9 client pour \u00e9viter d’\u00e9puiser les limites de d\u00e9bit de l’API.<\/p>\nErreurs courantes li\u00e9es aux limites de d\u00e9bit des API<\/h2>\n
\n
\n
Comment les principaux fournisseurs d’API mettent-ils en \u0153uvre les limites de d\u00e9bit de l’API ?<\/h2>\n
\n
retry_after<\/code> que vous pouvez utiliser pour attendre avant d’envoyer une autre requ\u00eate.<\/li>\nx-rate-limit-reset<\/code> qui vous indiquera quand vous pourrez reprendre l’acc\u00e8s.<\/li>\nX-Ratelimit-Used<\/code>, X-Ratelimit-Remaining<\/code>, et X-Ratelimit-Reset<\/code>, ce qui vous permet de d\u00e9terminer quand la limite pourrait \u00eatre d\u00e9pass\u00e9e et de quelle mani\u00e8re<\/li>\nX-App-Usage<\/code> ou X-Ad-Account-Usage<\/code> pour vous aider \u00e0 comprendre quand votre utilisation sera limit\u00e9e.<\/li>\n<\/ul>\n\nR\u00e9sum\u00e9<\/h2>\n