Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La limitación de velocidad es un mecanismo de control que utilizan las API en la nube para regular la cantidad de solicitudes que un usuario puede realizar en un tiempo específico. Los productores de API en la nube usan la limitación de velocidad para asegurarse de que el flujo de solicitudes no sobrecarga el servicio. La limitación de velocidad establece un límite en la velocidad y el volumen de las llamadas a la API. Los límites de tasa suelen definirse en términos de solicitudes por unidad de tiempo.
¿Por qué las API en la nube usan la limitación de velocidad?
- Evite la sobrecarga. La limitación de velocidad garantiza que el servidor de API permanezca estable y con capacidad de respuesta, ya que impide que cualquier usuario o servicio único lo inunde con demasiadas solicitudes.
- Asegúrese de un uso justo. La limitación de velocidad aplica políticas de uso justo al garantizar que ningún usuario monopolice los recursos de la API. La limitación de velocidad permite un acceso equitativo a todos los usuarios.
- Aumentar la seguridad. La limitación de velocidad ayuda a mitigar los ataques de denegación de servicio distribuido y otros comportamientos abusivos al restringir el número de solicitudes de fuentes potencialmente maliciosas.
- Gestionar costes. En el caso de los proveedores de servicios en la nube, la limitación de velocidad ayuda a administrar los costos operativos evitando un uso impredecible o excesivo de los recursos.
- Mantener la calidad del servicio. La limitación de velocidad garantiza una calidad de servicio constante para todos los usuarios al evitar picos de tráfico.
Cómo experimenta la limitación de velocidad en las aplicaciones
Al compilar aplicaciones que integran las API en la nube, consulte su documentación para comprobar si admiten la limitación de velocidad. Si lo hacen, recibirá los encabezados de respuesta RateLimit-... o X-RateLimit-... con información sobre los límites de frecuencia. Puede usar esta información en la aplicación para asegurarse de que no supera los límites de velocidad de la API. Por ejemplo, el RateLimit-Remaining encabezado indica el número de solicitudes restantes en la ventana actual. Si recibes una respuesta con este encabezado establecido en 0, sabrás que has alcanzado el límite de frecuencia y debes esperar a la siguiente ventana antes de enviar otra solicitud. El RateLimit-Reset encabezado indica la hora en que se restablece el límite de velocidad. Algunas API envían los RateLimit-... encabezados solo después de alcanzar un umbral. Un ejemplo es cuando le quedan 10% de las solicitudes.
Cuando superas el límite de frecuencia, la API limita tus solicitudes y devuelve un código de estado HTTP 429 Too Many Requests . Algunas API también pueden enviar un Retry-After encabezado para indicar cuánto tiempo debes esperar antes de enviar otra solicitud. No todas las API siguen este patrón. GitHub, por ejemplo, puede responder con 403 en lugar de 429.
Para evitar la limitación de tráfico y garantizar que tu aplicación siga respondiendo, implementa la limitación de tasa en tu aplicación. Dependiendo de su stack tecnológico, distintas bibliotecas pueden ayudarle a gestionar la limitación de tasa en su aplicación. Después de implementar la limitación de velocidad en la aplicación, pruebe si controla la limitación de velocidad correctamente.
¿Cómo afecta la limitación de velocidad a la aplicación?
Cuando una API comienza a devolver respuestas 429, una aplicación que no las gestiona se bloquea, muestra un error genérico, vuelve a intentarlo tan rápido que sigue sufriendo limitación de tasa o descarta datos silenciosamente. Rara vez ves nada de esto mientras desarrollas, ya que la API es rápida, eres el único usuario y los datos de prueba son pequeños.
Cómo probar que la aplicación controla los límites de tasa
| Approach | Lo que encuentras | Lo que te pierdes |
|---|---|---|
| A la espera de la producción | Límites de tasa reales | Todo, hasta que un usuario lo pulse |
| Simula la API en tus pruebas o deja que tu agente de programación escriba la simulación | Si su rama de reintento se ejecuta o no | Los códigos de estado real de la API, los encabezados de límite de velocidad y los cuerpos de error y la directiva de reintento del SDK. Tu aplicación también necesita un conmutador exclusivo para pruebas para acceder a la simulación. |
| Llama a la API real hasta que te limite el tráfico | Comportamiento real | No puedes alcanzar el límite a voluntad, agotas tu cuota real y algunos límites solo se restablecen tras una hora |
| Interceptar el tráfico real de la aplicación y simular el límite | Direcciones URL reales, el SDK real y la directiva de reintento, y los encabezados propios de la API, con el límite que elija. | Tu código por sí solo. Mantenga las pruebas unitarias para eso. |
Pruébalo en tu app
Dev Proxy cuenta las solicitudes que realiza tu aplicación a las API que elijas, añade encabezados de limitación de tasa a las respuestas y devuelve 429 cuando tu aplicación supera el límite, mientras que tu aplicación sigue realizando llamadas a las URL reales. También indica cuándo la aplicación llama a la API de nuevo antes de que se restablezca el límite.
Descargue la configuración preestablecida de la API a la que llama la aplicación e inicie Dev Proxy con ella:
devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"
Para las llamadas de Microsoft Graph a OneDrive y SharePoint (/drive, /shares, /sites), utiliza la configuración preestablecida microsoft-graph-rate-limiting. Para establecer su propio límite para cualquier API, consulte Simular respuestas de API con límite de tasa. Para instalar Dev Proxy, consulte Configurar Dev Proxy.