Las API son una forma estupenda de que las aplicaciones de software se comuniquen entre s\u00ed. Permiten que las aplicaciones de software interact\u00faen y compartan recursos o privilegios.<\/p>\n
Hoy en d\u00eda, muchas empresas B2B ofrecen sus servicios a trav\u00e9s de APIs que pueden ser consumidas por apps hechas en cualquier lenguaje de programaci\u00f3n y framework. Sin embargo, esto las hace vulnerables a los ataques DoS y DDoS, y tambi\u00e9n puede provocar una distribuci\u00f3n desigual del ancho de banda entre los usuarios. Para hacer frente a estos problemas, se aplica una t\u00e9cnica conocida como limitaci\u00f3n de la tasa de la API. La idea es sencilla \u2014 limitas el n\u00famero de peticiones que los usuarios pueden hacer a tu API.<\/p>\n
En esta gu\u00eda, aprender\u00e1s qu\u00e9 es la limitaci\u00f3n de la tasa de la API, las m\u00faltiples formas en que puede implementarse y algunas pr\u00e1cticas recomendadas y ejemplos que debes recordar al configurar los l\u00edmites de la tasa de la API.
\n
En palabras sencillas, la limitaci\u00f3n de la tasa de API consiste en establecer un umbral o l\u00edmite sobre el n\u00famero de veces que los usuarios pueden acceder a una API<\/a>. Los l\u00edmites pueden decidirse de m\u00faltiples maneras.<\/p>\n Una de las formas de establecer un l\u00edmite de tasa es reducir el n\u00famero de veces que un usuario concreto puede acceder a la API<\/a> en un plazo determinado. Esto se puede conseguir contando el n\u00famero de solicitudes realizadas utilizando la misma clave API o direcci\u00f3n IP, y cuando se alcanza un umbral, se limitan o deniegan m\u00e1s solicitudes.<\/p>\n En muchos casos, los desarrolladores quieren distribuir equitativamente el ancho de banda disponible para su API entre determinadas ubicaciones geogr\u00e1ficas.<\/p>\n El reciente servicio de la versi\u00f3n preliminar de ChatGPT<\/a> es un buen ejemplo de limitaci\u00f3n de tasa basada en la ubicaci\u00f3n<\/a>, ya que empezaron a limitar las solicitudes en funci\u00f3n de la ubicaci\u00f3n de los usuarios en la versi\u00f3n gratuita del servicio una vez que se lanz\u00f3 la versi\u00f3n de pago. Ten\u00eda sentido, ya que se supon\u00eda que la versi\u00f3n preliminar gratuita iba a ser utilizada por personas de todo el mundo para generar una buena muestra de datos de uso del servicio.<\/p>\n La limitaci\u00f3n de tarifa basada en el servidor es un l\u00edmite de tarifa interno implementado en el lado del servidor para garantizar una distribuci\u00f3n equitativa de los recursos del servidor, como CPU, memoria, espacio en disco, etc. Se realiza implementando un l\u00edmite en cada servidor de un despliegue.<\/p>\n Cuando un servidor alcanza su l\u00edmite, las dem\u00e1s solicitudes entrantes se dirigen a otro servidor con capacidad disponible. Si todos los servidores han alcanzado su capacidad, el usuario recibe una respuesta 429 Too Many Request<\/a>. Es importante se\u00f1alar que los l\u00edmites de tasa basados en el servidor se aplican a todos los clientes, independientemente de su ubicaci\u00f3n geogr\u00e1fica, hora de acceso u otros factores.<\/p>\n\n Aparte de la naturaleza de la aplicaci\u00f3n de los l\u00edmites de tasas, tambi\u00e9n se pueden clasificar los l\u00edmites de tasas en funci\u00f3n de su efecto sobre el usuario final. Algunos tipos comunes son:<\/p>\n Hay m\u00faltiples razones por las que necesitar\u00edas implementar la limitaci\u00f3n de tasa en tus APIs web<\/a>. Algunas de las principales razones son:<\/p>\n La primera raz\u00f3n por la que deber\u00edas considerar la implementaci\u00f3n de un l\u00edmite de tasa de la API en tu aplicaci\u00f3n es para proteger tus recursos de la sobre explotaci\u00f3n por parte de usuarios con intenciones maliciosas. Los atacantes pueden utilizar t\u00e9cnicas como los ataques DDoS<\/a> para acaparar el acceso a tus recursos e impedir que tu aplicaci\u00f3n funcione normalmente para otros usuarios. Disponer de un l\u00edmite de tasa garantiza que no est\u00e1s facilitando a los atacantes la interrupci\u00f3n de tus API.<\/p>\n Adem\u00e1s de proteger tus recursos, el l\u00edmite de tasa te permite dividir los recursos de tu API entre los usuarios. Esto significa que puedes crear modelos de precios escalonados y atender las necesidades din\u00e1micas de tus clientes sin dejar que afecten a otros clientes.<\/p>\n La limitaci\u00f3n de tasas tambi\u00e9n equivale a la limitaci\u00f3n de costes. Esto significa que puedes hacer una distribuci\u00f3n inteligente de tus recursos entre tus usuarios. Con una estructura particionada, es m\u00e1s f\u00e1cil estimar el coste necesario para el mantenimiento del sistema. Los picos pueden gestionarse de forma inteligente mediante el aprovisionamiento o liberaci\u00f3n de la cantidad adecuada de recursos.<\/p>\n Muchas APIs se basan en una arquitectura distribuida que utiliza m\u00faltiples workers\/hilos\/instancias para gestionar las peticiones entrantes. En una estructura de este tipo, puedes utilizar l\u00edmites de tasa para controlar la carga de trabajo que se pasa a cada nodo worker. Esto puede ayudarte a garantizar que los nodos workers reciben cargas de trabajo equitativas y sostenibles. Puede a\u00f1adir o eliminar workers cuando sea necesario sin necesidad de reestructurar toda la pasarela API.<\/p>\n Otra forma habitual de controlar el uso de la API es establecer un l\u00edmite burst (tambi\u00e9n conocido como regulaci\u00f3n) en lugar de un l\u00edmite de tasa. Los l\u00edmites burst son l\u00edmites de tasa implementados para un intervalo de tiempo muy peque\u00f1o, digamos unos segundos. Por ejemplo, en lugar de establecer un l\u00edmite de 1,3 millones de solicitudes al mes, podr\u00edas establecer un l\u00edmite de 5 solicitudes por segundo. Aunque esto equivale al mismo tr\u00e1fico mensual, garantiza que tus clientes no sobrecarguen tus servidores enviando bursts de miles de peticiones a la vez.<\/p>\n En el caso de los l\u00edmites burst, las solicitudes suelen retrasarse hasta el siguiente intervalo en lugar de denegarse. Tambi\u00e9n suele recomendarse utilizar conjuntamente los l\u00edmites de tasa y burst para un control \u00f3ptimo del tr\u00e1fico y del uso.<\/p>\n En cuanto a la implementaci\u00f3n, hay algunos m\u00e9todos que puedes utilizar para configurar la limitaci\u00f3n de tasa de la API en tu aplicaci\u00f3n. Entre ellos est\u00e1n:<\/p>\n Uno de los m\u00e9todos pr\u00e1cticos m\u00e1s sencillos para restringir el acceso a la API son las colas de peticiones. Las colas de peticiones se refieren a un mecanismo en el que las solicitudes entrantes se almacenan en forma de cola y se procesan una tras otra hasta un cierto l\u00edmite.<\/p>\n Un caso de uso com\u00fan de las colas de peticiones es segregar las peticiones entrantes de usuarios gratuitos y de pago. A continuaci\u00f3n te explicamos c\u00f3mo puedes hacerlo en una aplicaci\u00f3n Express<\/a> utilizando el paquete La regulaci\u00f3n es otra t\u00e9cnica utilizada para controlar el acceso a las API. En lugar de cortar el acceso tras alcanzar un umbral, la regulaci\u00f3n se centra en nivelar los picos de tr\u00e1fico de la API aplicando umbrales peque\u00f1os para intervalos de tiempo reducidos. En lugar de establecer un l\u00edmite de tasa como 3 millones de llamadas al mes, la regulaci\u00f3n establece l\u00edmites de 10 llamadas por segundo. Una vez que un cliente env\u00eda m\u00e1s de 10 llamadas en un segundo, las siguientes peticiones en el mismo segundo se regulan autom\u00e1ticamente, pero el cliente recupera instant\u00e1neamente el acceso a la API en el siguiente segundo.<\/p>\n Puedes implementar la regulaci\u00f3n en Express utilizando el paquete Puedes probar la aplicaci\u00f3n utilizando una herramienta de prueba de carga como AutoCannon<\/a>. Puedes instalar AutoCannon ejecutando el siguiente comando en tu terminal:<\/p>\n Puedes probar la aplicaci\u00f3n utilizando lo siguiente:<\/p>\n La prueba utiliza 10 conexiones concurrentes que env\u00edan solicitudes a la API. Aqu\u00ed tienes el resultado de la prueba:<\/p>\n Dado que s\u00f3lo se permit\u00edan 10 solicitudes por segundo (con un burst adicional de 5 solicitudes), la API s\u00f3lo proces\u00f3 con \u00e9xito 114 solicitudes, y las restantes fueron respondidas con un c\u00f3digo de error 503 que ped\u00eda esperar alg\u00fan tiempo.<\/p>\n Aunque la limitaci\u00f3n de tasa parece un concepto sencillo que puede implementarse utilizando una cola, en realidad puede implementarse de m\u00faltiples formas que ofrecen diversas ventajas. Aqu\u00ed tienes algunos algoritmos populares utilizados para implementar la limitaci\u00f3n de tasa:<\/p>\n El algoritmo de ventana fija es uno de los algoritmos de limitaci\u00f3n de tasa m\u00e1s sencillos. Limita el n\u00famero de solicitudes que se pueden gestionar en un intervalo de tiempo fijo.<\/p>\n Estableces un n\u00famero fijo de solicitudes, digamos 100, que el servidor API puede gestionar en una hora. Ahora bien, cuando llega la petici\u00f3n 101, el algoritmo deniega su procesamiento. Cuando se restablezca el intervalo de tiempo (es decir, en la hora siguiente), se podr\u00e1n procesar otras 100 solicitudes entrantes.<\/p>\n Este algoritmo es f\u00e1cil de aplicar y funciona bien en muchos casos en los que es necesario limitar la tasa en el servidor para controlar el ancho de banda (a diferencia de la distribuci\u00f3n del ancho de banda entre los usuarios). Sin embargo, puede dar lugar a un tr\u00e1fico\/procesamiento irregular hacia los l\u00edmites del intervalo de tiempo fijado. El algoritmo de ventana deslizante es una alternativa mejor en los casos en los que se necesita un procesamiento uniforme.<\/p>\n El algoritmo de ventana deslizante es una variaci\u00f3n del algoritmo de ventana fija. En lugar de utilizar intervalos de tiempo fijos predefinidos, este algoritmo utiliza una ventana de tiempo m\u00f3vil para hacer un seguimiento del n\u00famero de solicitudes procesadas y entrantes.<\/p>\n En lugar de fijarse en los intervalos de tiempo absolutos (de, digamos, 60 segundos cada uno), como de 0s a 60s, de 61s a 120s, etc., el algoritmo de ventana m\u00f3vil se fija en los 60s anteriores desde que se recibe una solicitud. Supongamos que se recibe una solicitud en el segundo 82; entonces el algoritmo contar\u00e1 el n\u00famero de solicitudes procesadas entre los 22s y los 82s (en lugar del intervalo absoluto de 60s a 120s) para determinar si esta solicitud se puede procesar o no. Esto puede evitar situaciones en las que se procese un gran n\u00famero de solicitudes tanto en el segundo 59 como en el 61, sobrecargando el servidor durante un periodo muy corto.<\/p>\n Este algoritmo gestiona mejor el tr\u00e1fico de burst, pero puede ser m\u00e1s dif\u00edcil de implementar y mantener que el algoritmo de ventana fija.<\/p>\n En este algoritmo, se llena un cubo (bucket) ficticio con tokens, y cada vez que el servidor procesa una solicitud, se saca un token del cubo. Cuando el cubo est\u00e1 vac\u00edo, el servidor no puede procesar m\u00e1s solicitudes. Las solicitudes posteriores se retrasan o deniegan hasta que se vuelva a llenar el cubo.<\/p>\n El token bucket se rellena a un ritmo fijo (conocido como ritmo de generaci\u00f3n de tokens), y el n\u00famero m\u00e1ximo de tokens que pueden almacenarse en el bucket tambi\u00e9n es fijo (conocido como profundidad del bucket).<\/p>\n Controlando la tasa de regeneraci\u00f3n de tokens y la profundidad del cubo, puedes controlar la tasa m\u00e1xima de flujo de tr\u00e1fico permitida por la API. El paquete La mayor ventaja de este algoritmo es que soporta tr\u00e1fico en burst siempre que quepa en la profundidad del bucket. Esto es especialmente \u00fatil para el tr\u00e1fico impredecible.<\/p>\n El algoritmo leaky bucket es otro algoritmo para gestionar el tr\u00e1fico de la API. En lugar de mantener una profundidad de cubo que determine cu\u00e1ntas solicitudes se pueden gestionar en un periodo de tiempo (como en un Token Bucket), permite un flujo fijo de solicitudes desde el cubo, que es an\u00e1logo al flujo constante de agua desde un cubo con fugas.<\/p>\n La profundidad del bucket, en este caso, se utiliza para determinar cu\u00e1ntas solicitudes pueden ponerse en cola para ser procesadas antes de que el cubo empiece a desbordarse, es decir, a denegar las solicitudes entrantes.<\/p>\n El leaky bucket promete un flujo constante de solicitudes y, a diferencia del token bucket, no gestiona los picos de tr\u00e1fico.<\/p>\n Ahora que ya sabes qu\u00e9 es la limitaci\u00f3n de tasa de la API y c\u00f3mo se aplica. Aqu\u00ed tienes algunas buenas pr\u00e1cticas que debes tener en cuenta al implementarla en tu aplicaci\u00f3n.<\/p>\n Cuando te plantees implantar un l\u00edmite de tasa de la API, intenta siempre ofrecer un nivel gratuito adecuado que tus posibles usuarios puedan utilizar para probar tu API. No tiene por qu\u00e9 ser muy generoso, pero debe ser suficiente para que puedan probar tu API c\u00f3modamente en su aplicaci\u00f3n de desarrollo.<\/p>\n Aunque los l\u00edmites de tasa de la API son vitales para mantener la calidad de los endpoints de tu API para tus usuarios, una peque\u00f1a capa gratuita no regulada puede ayudarte a conseguir nuevos usuarios.<\/p>\n Cuando un usuario supera el l\u00edmite de tasa de API establecido, hay un par de cosas que debe tener en cuenta para asegurarte de ofrecer una experiencia de usuario positiva y, al mismo tiempo, proteger tus recursos. Algunas preguntas que debes hacerte y consideraciones que debes tener en cuenta son:<\/p>\n Lo primero que debes tener en cuenta es informar a tus usuarios de que han superado el l\u00edmite de tasa de la API establecido. Para ello, debes cambiar la respuesta de la API por un mensaje preestablecido que explique el problema. Es importante que el c\u00f3digo de estado de esta respuesta sea 429 \u00abToo Many Requests\u00bb. <\/i>Tambi\u00e9n es habitual explicar el problema en el cuerpo de la respuesta. Aqu\u00ed tienes un ejemplo de cuerpo de respuesta:<\/p>\n El cuerpo de respuesta de ejemplo que se muestra arriba menciona el nombre y la descripci\u00f3n del error y tambi\u00e9n especifica una duraci\u00f3n (normalmente en segundos) tras la cual el usuario puede volver a intentar enviar solicitudes. Un cuerpo de respuesta descriptivo como \u00e9ste ayuda a los usuarios a comprender qu\u00e9 ha ido mal y por qu\u00e9 no han recibido la respuesta que esperaban. Tambi\u00e9n les permite saber cu\u00e1nto tiempo deben esperar antes de enviar otra solicitud.<\/p>\n Otro punto de decisi\u00f3n es qu\u00e9 hacer despu\u00e9s de que un usuario supere el l\u00edmite de tasa de la API establecido. Normalmente, impedir\u00edas que el usuario interactuara con el servidor envi\u00e1ndole una respuesta 429 \u00abToo Many requests\u00bb, como has visto antes. Sin embargo, tambi\u00e9n deber\u00edas considerar un enfoque alternativo\u2014la regulaci\u00f3n.<\/p>\n En lugar de cortar completamente el acceso al recurso del servidor, puedes ralentizar el n\u00famero total de peticiones que el usuario puede enviar en un periodo de tiempo. Esto es \u00fatil cuando quieres dar a tus usuarios un peque\u00f1o tir\u00f3n de orejas, pero permitirles seguir trabajando si reducen su volumen de peticiones.<\/p>\n Los l\u00edmites de tasa de la API son desagradables \u2014 impiden a tus usuarios interactuar con tus servicios API y utilizarlos. Esto es especialmente grave para los usuarios que necesitan realizar solicitudes similares una y otra vez, como acceder a un conjunto de datos de previsi\u00f3n meteorol\u00f3gica que s\u00f3lo se actualiza semanalmente o recuperar una lista de opciones para un men\u00fa desplegable que puede cambiar una vez cada mucho tiempo. En estos casos, un enfoque inteligente ser\u00eda implementar la cach\u00e9.<\/p>\n El almacenamiento en cach\u00e9<\/a> es una abstracci\u00f3n de almacenamiento de alta velocidad implementada en casos en los que el volumen de acceso a los datos es alto, pero los datos no cambian muy a menudo. En lugar de hacer una llamada a la API que podr\u00eda invocar varios servicios internos e incurrir en grandes gastos, podr\u00edas almacenar en cach\u00e9 los endpoints utilizados con m\u00e1s frecuencia, de modo que la segunda solicitud en adelante se sirva desde la cach\u00e9 est\u00e1tica, lo que suele ser m\u00e1s r\u00e1pido, m\u00e1s barato y puede reducir la carga de trabajo de tus servicios principales.<\/p>\n Puede darse otro caso en el que recibas un n\u00famero inusualmente alto de peticiones de un usuario. Incluso despu\u00e9s de establecer un l\u00edmite de tasa, est\u00e1n alcanzando constantemente su capacidad y se les limita la tasa. Estas situaciones indican que existe la posibilidad de un posible abuso de la API.<\/p>\n Para proteger tus servicios de la sobrecarga y mantener una experiencia uniforme para el resto de tus usuarios, deber\u00edas considerar la posibilidad de restringir completamente el acceso a la API al usuario sospechoso. Esto se conoce como interrupci\u00f3n del circuito, y aunque suena parecido a la limitaci\u00f3n de tasa, generalmente se utiliza cuando el sistema se enfrenta a una sobrecarga de peticiones y necesita tiempo para ralentizarse y recuperar su calidad de servicio.<\/p>\n Aunque los l\u00edmites de tasa de la API est\u00e1n pensados para distribuir tus recursos equitativamente entre tus usuarios, a veces pueden causar molestias innecesarias a tus usuarios o incluso indicar actividades sospechosas.<\/p>\n Configurar una soluci\u00f3n de monitorizaci\u00f3n robusta<\/a> para tu API puede ayudarte a comprender con qu\u00e9 frecuencia tus usuarios alcanzan los l\u00edmites de tasa, si necesitas o no reconsiderar los l\u00edmites generales teniendo en cuenta la carga de trabajo media de tus usuarios e identificar a los usuarios que alcanzan sus l\u00edmites con frecuencia (lo que podr\u00eda indicar que posiblemente necesitar\u00edan un aumento de sus l\u00edmites pronto o que necesitan ser monitorizados para detectar actividades sospechosas). En cualquier caso, una configuraci\u00f3n de supervisi\u00f3n activa te ayudar\u00e1 a comprender mejor el impacto de los l\u00edmites de tasa de tu API.<\/p>\n La limitaci\u00f3n de la tasa puede aplicarse a varios niveles (usuario, aplicaci\u00f3n o sistema). Mucha gente comete el error de establecer l\u00edmites de tasa s\u00f3lo en uno de estos niveles y esperar que cubra todos los casos posibles. Aunque no es exactamente un anti-patr\u00f3n, puede resultar ineficaz en algunos casos.<\/p>\n Si las peticiones entrantes sobrecargan la interfaz de red de tu sistema, puede que la limitaci\u00f3n de tasa a nivel de aplicaci\u00f3n ni siquiera sea capaz de optimizar las cargas de trabajo. Por eso es mejor establecer las reglas de limitaci\u00f3n de tasa en m\u00e1s de un nivel, preferiblemente en las capas superiores de tu arquitectura, para asegurarte de que no se crean cuellos de botella.<\/p>\n En esta secci\u00f3n, aprender\u00e1s c\u00f3mo probar los l\u00edmites de tasa de la API para un determinado endpoint de la API y c\u00f3mo implementar un control de uso en tu cliente para asegurarte de que no acabas agotando los l\u00edmites de tu API remota.<\/p>\n Para identificar el l\u00edmite de tasa de una API, lo primero que debes hacer siempre es leer la documentaci\u00f3n de la API para saber si los l\u00edmites est\u00e1n claramente definidos. En la mayor\u00eda de los casos, los documentos de la API te indicar\u00e1n el l\u00edmite y c\u00f3mo se ha implementado. Deber\u00edas recurrir a \u00abprobar\u00bb el l\u00edmite de tasa de la API para identificarlo s\u00f3lo cuando no puedas identificarlo a partir de los documentos de la API, el soporte o la comunidad. Esto se debe a que probar una API para encontrar su l\u00edmite de tasa significa que acabar\u00e1s agotando tu l\u00edmite de tasa al menos una vez, lo que podr\u00eda incurrir en costes financieros y\/o indisponibilidad de la API durante un cierto tiempo.<\/p>\n Si quieres identificar manualmente el l\u00edmite de tasa, primero debes empezar con una herramienta sencilla de pruebas de API, como Postman, para hacer peticiones manualmente a la API y ver si puedes agotar su l\u00edmite de tasa. Si no puedes, entonces puedes utilizar una herramienta de pruebas de carga como Autocannon o Gatling para simular un gran n\u00famero de solicitudes y ver cu\u00e1ntas solicitudes gestiona la API antes de que empiece a responder con un c\u00f3digo de estado 429.<\/p>\n Otro enfoque puede ser utilizar una herramienta de comprobaci\u00f3n de l\u00edmite de tasa como la de AppBrokers Sin embargo, si no est\u00e1s seguro del l\u00edmite de tasa de una API, siempre puedes intentar estimar tus requisitos de solicitud y establecer l\u00edmites en el lado del cliente para asegurarte de que el n\u00famero de solicitudes de tu aplicaci\u00f3n no supere esa cifra. Aprender\u00e1s c\u00f3mo hacerlo en la siguiente secci\u00f3n.<\/p>\n Si realizas llamadas a una API desde tu c\u00f3digo, es posible que desees implementar reguladores en tu lado para asegurarte de que no acabas realizando accidentalmente demasiadas llamadas a la API y agotando tu l\u00edmite de API. Hay varias formas de hacerlo. Una de las formas m\u00e1s populares es utilizar el m\u00e9todo throttle de la biblioteca de utilidades lodash.<\/p>\n Antes de empezar a regular una llamada a la API, tendr\u00e1s que crear una API. Aqu\u00ed tienes un c\u00f3digo de ejemplo para una API basada en Node.js que imprime en la consola el n\u00famero medio de solicitudes que recibe por minuto:<\/p>\n Una vez que se ejecute esta aplicaci\u00f3n, imprimir\u00e1 el n\u00famero medio de solicitudes recibidas cada segundo:<\/p>\n A continuaci\u00f3n, crea un nuevo archivo JavaScript con el nombre test-throttle.js<\/b>\u00a0y guarda en \u00e9l el siguiente c\u00f3digo:<\/p>\n Una vez que ejecutes este script, observar\u00e1s que el n\u00famero medio de peticiones del servidor se aproxima a 10:<\/p>\n \u00bfQu\u00e9 pasar\u00eda si esta API s\u00f3lo permitiera 6 peticiones por segundo, por ejemplo? Querr\u00edas mantener el promedio de peticiones por debajo de esa cifra. Sin embargo, si tu cliente env\u00eda una solicitud bas\u00e1ndose en alguna actividad del usuario, como el clic de un bot\u00f3n o un desplazamiento, es posible que no puedas limitar el n\u00famero de veces que se activa la llamada a la API.<\/p>\n La funci\u00f3n A continuaci\u00f3n, actualiza el archivo test-throttle.js<\/b> para que contenga el siguiente c\u00f3digo:<\/p>\n Ahora, si miras los registros del servidor, ver\u00e1s una salida similar:<\/p>\n Esto significa que aunque tu aplicaci\u00f3n est\u00e1 llamando a la funci\u00f3n Cuando trabajas con APIs de tasa limitada, puedes encontrarte con una variedad de respuestas que indican que se ha superado un l\u00edmite de tasa. En la mayor\u00eda de los casos, recibir\u00e1s el c\u00f3digo de estado 429 con un mensaje similar a uno de estos:<\/p>\n Sin embargo, el mensaje que recibas depende de la implementaci\u00f3n de la API que est\u00e9s utilizando. Esta implementaci\u00f3n puede variar, y puede que algunas API ni siquiera utilicen el c\u00f3digo de estado 429. Aqu\u00ed tienes otros tipos de c\u00f3digos de error de l\u00edmite de tasa y mensajes que puedes recibir al trabajar con APIs de tasa limitada:<\/p>\n A la hora de establecer el l\u00edmite de tasa de tu API, puede ser \u00fatil echar un vistazo a c\u00f3mo lo hacen algunos de los principales proveedores de API:<\/p>\n Cuando se crean API, es crucial garantizar un control \u00f3ptimo del tr\u00e1fico. Si no vigilas de cerca la gesti\u00f3n del tr\u00e1fico, pronto acabar\u00e1s con una API sobrecargada y no funcional. A la inversa, cuando trabajes con una API de tasa limitada, es importante que entiendas c\u00f3mo funciona la limitaci\u00f3n de tasa y c\u00f3mo debes utilizar la API para garantizar la m\u00e1xima disponibilidad y uso.<\/p>\n En esta gu\u00eda, has aprendido sobre la limitaci\u00f3n de tasa de la API, por qu\u00e9 es necesaria, c\u00f3mo se puede implementar y algunas buenas pr\u00e1cticas que debes tener en cuenta cuando trabajes con l\u00edmites de tasa de la API.<\/p>\n \u00a1Echa un vistazo al Alojamiento de Aplicaciones<\/a> de Kinsta y pon en marcha tu pr\u00f3ximo proyecto Node.js<\/a> hoy mismo!<\/p>\n \u00bfTrabajas con una API de tarifa limitada? \u00bfO has implementado la limitaci\u00f3n de tarifas en tu propia API? H\u00e1znoslo saber en los comentarios<\/i><\/p>\n","protected":false},"excerpt":{"rendered":" Las API son una forma estupenda de que las aplicaciones de software se comuniquen entre s\u00ed. Permiten que las aplicaciones de software interact\u00faen y compartan recursos …<\/p>\n","protected":false},"author":199,"featured_media":67274,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kinsta_gated_content":false,"_kinsta_gated_content_redirect":"","footnotes":""},"tags":[],"topic":[1270],"class_list":["post-67273","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","topic-api"],"yoast_head":"\n1. L\u00edmites Basados en el Usuario<\/h3>\n
2. L\u00edmites Basados en la Ubicaci\u00f3n<\/h3>\n
3. L\u00edmites Basados en el Servidor<\/h3>\n
Tipos de L\u00edmites de la Tasa API<\/h2>\n
\n
\u00bfPor Qu\u00e9 Es Necesaria la Limitaci\u00f3n de la Tasa?<\/h2>\n
1. Proteger el Acceso a los Recursos<\/h3>\n
2. Repartir la Cuota Entre los Usuarios<\/h3>\n
3. Mejorar la Rentabilidad<\/h3>\n
4. Gestionar el Flujo entre Workers<\/h3>\n
Entendiendo los l\u00edmites de Burst<\/h2>\n
3 M\u00e9todos de Aplicaci\u00f3n del L\u00edmite de Tasa<\/h2>\n
1. Colas de Peticiones<\/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. Regulaci\u00f3n (Throttling)<\/h3>\n
express-throttle<\/code>. Aqu\u00ed tienes un ejemplo de aplicaci\u00f3n Express que muestra c\u00f3mo configurar la regulaci\u00f3n en tu aplicaci\u00f3n:<\/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. Algoritmos de limitaci\u00f3n de tasa<\/h3>\n
Algoritmo de Ventana Fija<\/h4>\n
Algoritmo de Ventana Deslizante<\/h4>\n
Algoritmo Token Bucket (Algoritmo del Cubo de Tokens)<\/h4>\n
express-throttle<\/code> que has visto antes utiliza el algoritmo del cubo de tokens para estrangular o controlar el flujo de tr\u00e1fico de la API.<\/p>\nAlgoritmo Leaky Bucket<\/h4>\n
Buenas Pr\u00e1cticas para Limitar la Tasa de la API<\/h2>\n
Ofrece un Nivel Gratuito para que los Usuarios Exploren tus Servicios<\/h3>\n
Decide Qu\u00e9 Ocurre Cuando se Supera el L\u00edmite de Tasa<\/h3>\n
\u00bfQu\u00e9 C\u00f3digo y Mensaje de Error Ver\u00e1n Tus Usuarios?<\/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>\n\u00bfSe Ralentizar\u00e1n o Detendr\u00e1n por Completo las Nuevas Solicitudes?<\/h4>\n
Tipo Considera el Almacenamiento en Cach\u00e9 y la Rotura de Circuitos<\/h3>\n
Monitorea de Cerca tu Configuraci\u00f3n<\/h3>\n
Implementa la Limitaci\u00f3n de Tasa en M\u00faltiples Capas<\/h3>\n
Trabajar con L\u00edmites de Tasa de la API<\/h2>\n
C\u00f3mo Probar los L\u00edmites de Tasa de la API<\/h3>\n
rate-limit-test-tool<\/a><\/code>. Herramientas dedicadas como \u00e9sta automatizan el proceso por ti y tambi\u00e9n te proporcionan una interfaz de usuario para analizar detenidamente los resultados de la prueba.<\/p>\nC\u00f3mo Limitar las Llamadas a la 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 lodash<\/code> puede ayudarte en este caso. En primer lugar, instala la biblioteca ejecutando el siguiente comando:<\/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 veces por segundo, la funci\u00f3n de regulaci\u00f3n se asegura de que s\u00f3lo se llame 5 veces por segundo, ayud\u00e1ndote a mantenerte por debajo del l\u00edmite de tasa. As\u00ed es como puedes configurar la regulaci\u00f3n del lado del cliente para evitar agotar los l\u00edmites de tasa de la API.<\/p>\nErrores Comunes del L\u00edmite de Tasa de la API<\/h2>\n
\n
\n
C\u00f3mo Implementan los Principales Proveedores de API los L\u00edmites de Tasa de la API<\/h2>\n
\n
retry_after<\/code> que puedes utilizar para esperar antes de enviar otra solicitud.<\/li>\nx-rate-limit-reset<\/code> que te indicar\u00e1 cu\u00e1ndo puedes reanudar el acceso.<\/li>\nX-Ratelimit-Used<\/code>, X-Ratelimit-Remaining<\/code>, y X-Ratelimit-Reset<\/code> con los que puedes determinar cu\u00e1ndo podr\u00eda superarse el l\u00edmite y c\u00f3mo lo har\u00e1s<\/li>\nX-App-Usage<\/code> o X-Ad-Account-Usage<\/code> para ayudarte a comprender cu\u00e1ndo se estrangular\u00e1 tu uso.<\/li>\n<\/ul>\n\nResumen<\/h2>\n