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 solicitudes es una técnica que utilizan las API en la nube para restringir el número de solicitudes que se pueden realizar en un periodo de tiempo concreto. La limitación de solicitudes garantiza que la API siga estando disponible y responda a todos los usuarios. También evita que un solo usuario consuma demasiados recursos.
Puede experimentar la limitación de varias maneras. Una forma común es mediante el uso de códigos de estado HTTP. Por ejemplo, cuando se supera el número permitido de solicitudes, la API podría devolver un código de estado 429 Too Many Requests. Esta respuesta indica que ha emitido demasiadas solicitudes en un período de tiempo específico y que debe ralentizarse. No todas las API usan 429: GitHub también puede responder con 403y Anthropic usa 529 cuando se sobrecarga toda la API.
Además de los códigos de estado, algunas API proporcionan más información en los encabezados de respuesta o el cuerpo. Por ejemplo, pueden usar el Retry-After encabezado para indicar cuánto tiempo debe esperar antes de realizar otra solicitud.
Debes conocer los límites de limitación de solicitudes de las API que utilizas y saber cómo administrar la limitación de solicitudes en tus aplicaciones, para que estas sigan respondiendo y sean fiables cuando la API se encuentre bajo una carga elevada.
Cómo afecta la limitación a tu aplicación
Cuando una API limita la aplicación y la aplicación no gestiona esa situación, la aplicación se bloquea, muestra un error genérico, reintenta tan rápido que sigue sujeta a limitación de velocidad 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 gestiona la limitación de tasa
| Approach | Lo que encuentras | Lo que te pierdes |
|---|---|---|
| A la espera de la producción | Limitación real | Todo ello, hasta que un usuario lo alcance. |
| Simula la API en tus pruebas o deja que tu agente de codificación escriba el mock | Si se ejecuta tu rama de reintentos. | Los códigos de estado reales de la API, Retry-Afterlos encabezados y los cuerpos de error, así como la directiva de reintentos de tu SDK. La aplicación también necesita una opción solo para pruebas para acceder al mock. |
| Llama a la API real hasta que te limite el tráfico | Comportamiento real | No puedes activar la limitación de forma selectiva, y agotarás tu cuota real |
| Intercepta el tráfico real de tu aplicación y simula la limitación | Direcciones URL reales, el SDK real y la directiva de reintento, y si la aplicación espera tanto tiempo como indica Retry-After |
Tu código de forma aislada. Reserva tus pruebas unitarias para eso. |
Pruébalo en tu app
Dev Proxy devuelve respuestas de limitación de velocidad para las API que elijas, mientras que la aplicación sigue llamando a las direcciones URL reales. También te indica cuándo tu aplicación vuelve a llamar a la API antes de que Retry-Aftertranscurra el tiempo establecido.
Descargue la configuración preestablecida de la API a la que llama la aplicación e inicie Dev Proxy con ella:
devproxy config get microsoft-graph-rate-limiting
devproxy --config-file "~dataFolder/configs/microsoft-graph-rate-limiting/.devproxy/devproxyrc.json"
| API | Preset |
|---|---|
Microsoft Graph (OneDrive y SharePoint: /drive, /shares, /sites) |
microsoft-graph-rate-limiting |
| GitHub | github-rate-limiting |
| OpenAI | openai-throttling |
| Anthropic | anthropic-throttling |
Para cualquier otra API, consulta Comprobar que mi aplicación administra correctamente la limitación de tráfico. Para instalar Dev Proxy, consulte Configurar Dev Proxy.