¿Qué es la limitación de frecuencia?

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 restricción y asegurarse de que su aplicación siga respondiendo, implemente la limitación de tasa en su 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
Esperar a que esté en producción Límites de tasa reales Todo, hasta que un usuario lo pulse
Simula la API en las pruebas o deja que el agente de codificación escriba el simulacro 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. La aplicación también necesita una opción solo para pruebas para acceder al mock.
Llame a la API real hasta que te aplique limitación de tasa. Comportamiento real No se puede alcanzar el límite bajo demanda, se usa la cuota real y algunos límites se restablecen solo después de 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 de la aplicación a las API que elija, agrega encabezados de límite de velocidad a las respuestas y devuelve 429 cuando la aplicación supera el límite, mientras que la aplicación sigue llamando a las direcciones 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), use el valor preestablecido microsoft-graph-rate-limiting. Para establecer su propio límite para cualquier API, consulte Simulate rate limit API responses. Para instalar Dev Proxy, consulte Configurar Dev Proxy.

Pasos siguientes

Cómo controlar la limitación de velocidad

  • Se actualizó por última vez el