¿El final de REST? Cuando HTTP/3 y WebSockets dejan de ser una opción y pasan a ser clave

Las métricas decían que la plataforma funcionaba dentro de lo esperado. Latencias aceptables, error rate plano, infraestructura estable. Sin embargo, los mensajes de tus usuarios repetían una idea difícil de cuantificar:

“La aplicación se nota lenta.”

No es lenta. Se “siente” lenta. Y cuando eso ocurre, rara vez el problema está en una línea de código concreta.

Cuando el modelo REST deja de encajar

Durante años, REST fue una decisión natural. La forma más limpia y razonable de conectar frontend y backend. El modelo es simple: alguien pide algo, alguien responde. Una conversación breve, educada, eficiente.

Ese modelo funcionaba porque las aplicaciones también eran así. Pantallas que cargaban, formularios que se enviaban, páginas que se refrescaban. Incluso cuando añadimos JavaScript, la lógica seguía siendo la misma, solo un poco más rápida.

El problema llegó cuando las aplicaciones dejaron de comportarse como documentos.

Hoy trabajamos con interfaces que no esperan. Dashboards que cambian sin interacción, precios que se actualizan en tiempo real, notificaciones que aparecen mientras el usuario está haciendo otra cosa. Interfaces que no “cargan”, sino que viven.

Y aun así, seguimos usando el mismo patrón: el cliente preguntando constantemente si algo ha cambiado. REST no estaba mal diseñado, simplemente estaba pensado para otra clase de conversación.

El coste invisible del polling en REST

Desde fuera, el sistema seguía siendo elegante. Endpoints claros, JSON limpio, cachés afinadas. Nada parecía especialmente incorrecto. Por debajo, el coste crecía en silencio.

Cada navegador repetía las mismas peticiones. Cada balanceador distribuía tráfico redundante. Cada servicio respondía una y otra vez con la misma información, solo para confirmar que nada había cambiado.

En los gráficos de infraestructura, todo parecía bajo control. Pero desgraciadamente en la experiencia del usuario, no.

Las gráficas se movían a saltos. Los datos llegaban con retraso. La confianza se ha podido erosionar poco a poco. Y eso es lo más peligroso, cuando el producto no falla, pero tampoco transmite fiabilidad.

HTTP/3 no cambia el qué, cambia el cómo

Durante mucho tiempo, HTTP fue una autopista pensada para trayectos cortos. Entrar, salir, volver a entrar. TCP hacía bien su trabajo, pero asumía un mundo relativamente estable: conexiones limpias, poca pérdida de paquetes, redes predecibles.

Ese mundo ya no existe, es por ello que HTTP/3, al apoyarse en QUIC, no promete magia. Promete algo más humilde y más importante: resiliencia en condiciones reales. Redes móviles inestables, cambios constantes de IP, latencias irregulares.

HTTP/3 en QUIC no elimina REST, pero deja claro que el paradigma de “abre, pide, cierra” empieza a chirriar cuando lo repites cientos de veces por minuto.

Es una infraestructura pensada para mantener conversaciones, no para intercambiar notas.

Cuando el servidor empieza a hablar

El cambio real no ha llegado solo con HTTP/3, sino cuando dejamos de forzar el modelo request-response para cosas que claramente no lo eran. En un sistema de precios en tiempo real, el cliente no necesita preguntar, necesita escuchar.

WebSockets no son una novedad, pero durante años se trataron como algo exótico, casi peligroso. Algo que se usa “solo si es imprescindible”. Sin embargo, cuando el producto exige inmediatez, forzar REST es lo verdaderamente artificial.

Al abrir un canal persistente, el sistema dejó de trabajar contra sí mismo. El servidor hablaba cuando había algo que decir. El resto del tiempo, simplemente callaba.

No hubo que reescribir la lógica de negocio. Solo cambiar la forma en la que la información viajaba.

La diferencia no siempre se ve en los logs

Tras el cambio, las métricas mejoraron, con latencias más bajas, menos tráfico redundante, menos presión sobre servicios calientes.

Lo interesante fue otra cosa, los equipos dejamos de discutir contra el protocolo y dejamos de hacer soluciones “creativas” para simular tiempo real. Es así que desaparecieron capas pensadas solo para amortiguar polling.

La parte incómoda: el internet real

Activar HTTP/3 no fue nada facil, ya que algunos proveedores bloquean UDP y algunos CDNs tenían implementaciones inmaduras para este entorno.

Además algunas redes móviles penalizaban el tráfico de formas imposibles de detectar desde un escritorio con fibra y hubo que aceptar una verdad incómoda: no todos los usuarios podrán usarlo siempre, y no pasa nada.

Diseñar fallback no es rendirse. Es entender dónde estás desplegando tu producto. HTTP/3 funciona extraordinariamente bien cuando funciona, y cuando no, HTTP/2 sigue siendo un plan B sólido.

El error no es tener fallback. El error es no asumir que lo necesitarás.

Conclusión

Nada de esto significa que REST haya terminado. Sigue siendo excelente para lo que siempre fue: operaciones claras, estados definidos, flujos donde unos cientos de milisegundos no cambian la percepción.

Lo que está muriendo es la costumbre de usarlo para todo, incluso cuando el propio producto pide otra cosa. En cuanto trabajas en serio con experiencias en tiempo real, hay un punto de no retorno. Volver al polling se siente como poner parches donde antes había intención.

REST no desaparecerá por una decisión de estándares ni por una moda. Desaparecerá poco a poco, cada vez que un equipo se pregunte por qué su aplicación “funciona”, pero no transmite fluidez. Cada vez que alguien note que el protocolo no acompaña al producto.

El verdadero cambio ocurre cuando dejamos de preguntar “¿qué tecnología usamos?” y empezamos a preguntarnos “¿qué conversación necesita este producto?”, ahí, casi siempre, REST deja de ser la respuesta automática.