Resumen

  • 429 Too Many Requests comunica que la corriente atribuida por el servidor cruzó un presupuesto definido localmente; no afirma que el mensaje esté mal formado ni identifica por sí solo a una persona.
  • La respuesta puede incluir Retry-After, pero esperar no reserva capacidad. La próxima operación vuelve a depender de la política, la autorización, la carga y el estado vigentes.
  • El estándar no define sujeto, contador ni alcance. Esa libertad preserva la operación local y también deja una obligación: auditar a quién se hace esperar, por qué y con qué daño colateral.

El mensaje que no cambió

Un programa consulta una API cincuenta veces. La operación siguiente contiene los mismos campos válidos, llega a la misma dirección y presenta la misma autorización. Si el servidor la rechaza, la causa no tiene por qué estar en sus bytes. Vive en una relación histórica: ese servidor ha agrupado el mensaje con solicitudes anteriores y el total ha cruzado un umbral.

HTTP nació como un intercambio de peticiones y respuestas que pueden interpretarse una a una. Limitar frecuencia obliga, sin embargo, a recordar actividad. RFC 6585 incorporó en abril de 2012 un resultado común para esa memoria: 429. La representación debería explicar la condición y puede señalar cuánto conviene esperar.

El texto se detiene justo antes de diseñar la contabilidad. No define cómo reconoce el origen al usuario ni cómo suma peticiones. Admite contadores por recurso, por servidor o por un conjunto de servidores, y menciona credenciales o cookies como posibles identificadores. Así, dos servicios pueden cumplir el mismo RFC y aplicar políticas muy distintas.

La interoperabilidad está en la respuesta, no en la justicia del libro mayor.

El sujeto contado no viene dentro del código

Una persona no cabe automáticamente en una dirección IP. Detrás de una salida empresarial, un CGNAT o un servicio de privacidad pueden convivir muchas. Si el límite agrupa por dirección, el tráfico de una afecta a las demás. El servidor obtiene una señal temprana y barata; los usuarios reciben una identidad colectiva que quizá nunca conocieron.

Una cuenta autenticada parece más precisa, aunque tampoco resuelve todo. Puede reunir varios dispositivos, equipos de trabajo o procesos. Una clave puede compartirse, rotarse o ser robada. Una cookie distingue una sesión mientras exista, pero un cliente puede perderla o multiplicarla. Cada evidencia responde a una pregunta distinta.

Por eso 429 no debe leerse como “esta persona abusó”. Sólo sostiene algo más estrecho: el sujeto que la política construyó agotó el presupuesto que esa política le asignó. La autoridad de la negativa no puede superar la calidad de esa atribución.

Contar exige elegir qué mundo comparte el límite

Una cuota por recurso protege el componente caro sin cerrar funciones ordinarias. Una cuota para todo el servidor defiende una reserva común, pero puede valorar igual una comprobación mínima y una búsqueda costosa. Una cuota por organización aproxima capacidad y contrato; necesita que cada solicitud llegue al arrendatario correcto. Una cuota distribuida conserva la misma regla entre regiones, pero introduce retrasos de réplica y decisiones durante una partición.

También hace falta decidir cuándo nace la unidad. ¿Al recibir el mensaje, después de autenticarlo, cuando se admite o al terminar el trabajo? ¿Cuenta una respuesta redirigida? ¿Cuenta un flujo cancelado antes de completarse? ¿Dos reintentos del intermediario son uno para el cliente o dos para el origen? RFC 6585 no puede contestar sin apoderarse del diseño del servicio.

El límite es, pues, estado local detrás de un intercambio visible. El código muestra el resultado, no certifica el contador.

Un tiempo de regreso que no es una cita

Según RFC 9110, Retry-After acepta una fecha HTTP o un número no negativo de segundos. RFC 6585 permite acompañar 429 con ese campo, pero no lo exige. La semántica pide al agente que espere antes de volver; no promete que será atendido al regresar.

El detalle cambia la conducta. Una fecha depende de referencias temporales compatibles. Un retraso se mide desde la recepción y evita comparar directamente dos relojes. Ninguno impide que cientos de clientes despierten a la vez. Si todos liberan su cola en el límite exacto, una señal diseñada para calmar la demanda puede concentrarla.

El cliente necesita su propio criterio: dispersar reintentos, limitar intentos, respetar la caducidad del trabajo y conservar el significado de la operación. En métodos con efectos, el paso del tiempo no demuestra si un intercambio anterior actuó durante una avería de transporte. El temporizador no sustituye la evidencia de ejecución.

Frecuencia atribuida y servicio incapaz

Un 503 habla de incapacidad temporal del servidor por sobrecarga o mantenimiento. Un 429 habla de demasiadas solicitudes dentro del sujeto y periodo definidos por la política de tasa. Ambos pueden aconsejar una espera, pero describen centros de control diferentes.

Un arrendatario puede recibir 429 mientras otros siguen trabajando. Todo el servicio puede devolver 503 aunque ningún cliente haya agotado una asignación personal. Las dos condiciones pueden coincidir, y entonces el operador debe nombrar la causa que realmente decidió el rechazo.

Presentar una falta general de capacidad como error de un cliente traslada responsabilidad. Presentar un límite individual como caída total oculta qué camino continúa disponible. La precisión del estado importa porque orienta la siguiente acción.

Decir no también gasta

RFC 6585 observa que responder 429 a cada petición durante un ataque consume recursos. Por eso el servidor puede cortar conexiones o tomar otras medidas en vez de emitir siempre una explicación.

La ruta hasta un “no” puede incluir descifrado, análisis, autenticación, consulta a un contador remoto, creación del cuerpo y cifrado de la respuesta. Si el atacante compra ese trabajo con cada paquete, la amabilidad destruye el presupuesto protegido. Una denegación en el borde resulta más barata, pero quizá sólo vea una dirección compartida y no la identidad contractual.

La arquitectura debe balancear coste y prueba. Rechazar pronto reduce trabajo; rechazar con contexto reduce falsos positivos. No existe un punto universal porque el recurso escaso y la evidencia disponible pertenecen al operador.

Por qué el rechazo no puede quedarse en caché

RFC 6585 prohíbe almacenar 429. Es una decisión perecedera ligada a un sujeto, un instante, un alcance y un contador. Una copia reutilizada podría negar después de que terminó la ventana o aplicarse a una solicitud que no comparte el presupuesto original.

Un intermediario que administra su propia capacidad puede generar su propio 429. Lo que no debe hacer es convertir el antiguo veredicto de otro componente en contenido vigente. La prohibición mantiene la decisión junto al estado capaz de renovarla.

El límite de la afirmación

Tres dígitos no prueban mala intención, abuso, una persona única, una cuenta exacta ni un reparto justo. Tampoco reservan servicio futuro. Su contribución fue otra: ofrecer a clientes y servidores una rama común para una solicitud válida que llega después de agotarse una asignación local.

429 hizo visible una contabilidad sin nacionalizarla. La historia técnica termina ahí; la responsabilidad empieza preguntando quién quedó unido al contador y quién paga la espera.

Fuentes