Las API permiten que los productos intercambien información y activen acciones entre diferentes sistemas. Cada vez que una aplicación recupera el perfil de un cliente, verifica un pago, carga un mapa o envía una notificación, puede estar realizando una solicitud a una API.
Los proveedores de APIs utilizan límites de peticiones para controlar la demanda sobre su infraestructura compartida. La cuota puede depender del plan contratado, del endpoint o de la operación; un producto puede agotarla aunque el servicio del proveedor funcione correctamente.
Un límite de solicitudes define cuántas solicitudes puede realizar un usuario, aplicación o sistema dentro de un período específico. Por ejemplo, una API podría permitir 100 solicitudes por minuto, 5000 solicitudes por hora o una determinada cantidad de solicitudes por usuario.
Cuando se excede el límite, la API puede rechazar temporalmente solicitudes adicionales y devolver el código de estado HTTP 429 Demasiadas solicitudes.
El libro APIs para Product Managers aborda estas restricciones junto con las decisiones de integración que las introducen.
¿Qué son los límites de solicitudes de API?
Un límite de solicitudes de API es una regla que controla la frecuencia con la que un cliente puede enviar solicitudes a una API. Una integración que consulta el estado de los envíos puede compartir una cuota entre todos los clientes del producto. Actualizar cada pedido en cada visita puede agotarla durante una campaña, aunque cada cliente haga pocas consultas.
El ámbito de la cuota determina qué usuarios comparten capacidad. Un límite por cuenta tiene consecuencias distintas de uno que se aplica a toda la aplicación. Los límites se pueden aplicar de diferentes maneras. Un proveedor de API podría restringir las solicitudes:
- Por usuario o cuenta de cliente.
- Por aplicación o clave API.
- Por dirección IP.
- Por endpoint.
- Por segundo, minuto, hora o día.
Algunos proveedores también distinguen entre uso sostenido y breves ráfagas de tráfico. Es posible que una aplicación pueda realizar varias solicitudes rápidamente, pero no mantener esa frecuencia indefinidamente.
¿Qué significa el código de estado 429?
Cuando una aplicación realiza más solicitudes de las que permite la API, el servicio a menudo devolverá una respuesta 429 demasiadas solicitudes. Esto no significa necesariamente que la API no esté disponible o que algo haya fallado permanentemente. Normalmente significa que la aplicación debe ralentizarse y esperar antes de volver a intentarlo.
La respuesta puede incluir la cabecera Retry-After, expresada como una espera en segundos o una fecha HTTP. El cliente puede utilizar ese valor para programar otro intento. Algunos proveedores documentan también cabeceras de cuota y momentos de reinicio, con convenciones propias de cada API.
Si la aplicación ignora la respuesta y continúa realizando solicitudes, puede crear un bucle de reintento que genera aún más tráfico y empeora el problema original.
¿Por qué los Product Managers deberían preocuparse por los límites de peticiones?
Una cuota agotada cambia lo que el producto puede mostrar o completar mientras espera a disponer de capacidad. Ese comportamiento alternativo requiere una decisión de producto. Imagine que su producto utiliza una API externa para mostrar información de entrega. Si la aplicación excede el límite de solicitudes del proveedor, los usuarios pueden ver datos faltantes, información desactualizada, errores de carga o pantallas que parecen estar rotas.
El mismo problema puede afectar a los servicios de pago, sistemas de autenticación, mapas, herramientas de mensajería, plataformas de análisis y muchas otras capacidades del producto. Durante el discovery, Producto e Ingeniería pueden concretar la demanda prevista y la experiencia que recibirán los usuarios si se rechazan temporalmente las peticiones:
- ¿Qué límites impone el proveedor de API?
- ¿Los límites son globales o se aplican por usuario?
- ¿Qué sucede cuando los superamos?
- ¿Qué mensaje verán los usuarios?
- ¿Podemos almacenar información en caché en lugar de solicitarla repetidamente?
- ¿El tráfico esperado requerirá un plan más caro?
- ¿Cómo supervisaremos los errores de límite de solicitudes después del lanzamiento?
Estas preguntas son particularmente importantes al lanzar un producto en un nuevo mercado, ejecutar una campaña de marketing o introducir una característica que podría generar picos repentinos de tráfico.
¿Cómo puede un producto gestionar los límites de solicitudes de API?
Hay varias formas en que los equipos técnicos pueden reducir el riesgo de exceder los límites de una API. Los reintentos necesitan una política de espera y un punto en el que detenerse. Las esperas crecientes, a menudo con una variación aleatoria, permiten repartir las nuevas peticiones. En acciones que modifican datos también hay que comprobar si repetir una petición puede duplicar la operación.
La caché permite reutilizar una respuesta almacenada mientras siga siendo válida para la funcionalidad. El equipo debe acordar cuánto pueden envejecer los datos de envío, precios o cuentas antes de actualizarlos.
Controlar la frecuencia de las solicitudes: las solicitudes se pueden distribuir a lo largo del tiempo en lugar de enviarse todas a la vez. Esto es útil para procesos en segundo plano, sincronizaciones y operaciones masivas. Usar límites por usuario: los productos con muchos usuarios pueden establecer límites internos para evitar que una sola cuenta consuma demasiada capacidad.
Supervisar el uso de la API: los paneles y las alertas pueden ayudar a los equipos a detectar cuándo los volúmenes de solicitudes se acercan a los límites del proveedor. El enfoque correcto depende del producto, la importancia de los datos y la rapidez con la que cambia esa información.
Los límites de peticiones son un mecanismo de protección
La cuota del proveedor se convierte en una restricción de capacidad del producto. Prever la demanda exige estimar las peticiones de cada recorrido, el uso compartido y los periodos de mayor actividad, además del número de usuarios. Antes del lanzamiento conviene documentar el comportamiento alternativo, la política de reintentos y quién vigilará el consumo de cuota. Una sincronización en segundo plano puede admitir una espera que haría inutilizable un checkout interactivo.
Las definiciones HTTP pueden consultarse en RFC 6585, sección 4 y en la especificación de Retry-After.
