REST, GraphQL y WebSocket: los tres modos en que dos programas se hablan
Tres nombres que vas a oír en la misma reunión, y que resuelven problemas distintos. Sin tecnicismos y con la consecuencia práctica de cada uno.
Pedir de una carta cerrada, con los platos ya decididos de antemano. Pedir exactamente lo que hace falta, ni un ingrediente de más. Dejar la línea abierta con la cocina y que avisen en cuanto algo esté listo, sin tener que preguntar. Son tres formas distintas de que un programa le pida información a otro, y las vas a oír nombradas con las siglas REST, GraphQL y WebSocket en la misma reunión, sin que nadie se pare a explicar qué decide cada una ni por qué hay tres en vez de una sola.
Las tres son formas de usar la misma carta que ya sirvió para explicar qué es una API; lo que cambia entre ellas es cómo se pide y cuándo llega la respuesta. Da igual si nunca has escrito una línea de código: lo que importa es saber qué problema resuelve cada una, y qué se nota —en la factura, en la app, en la paciencia del equipo que lo mantiene— cuando se elige la que no tocaba.
#REST: pedir de un catálogo fijo
REST es la forma más extendida y la más sencilla de las tres: el sistema publica una lista fija de cosas que se pueden pedir —«dame los datos de este cliente», «dame el listado de pedidos de hoy»— y cada vez que necesitas algo, haces una petición nueva y recibes una respuesta completa. Es la carta de un restaurante normal: los platos están fijados de antemano, y cada vez que quieres algo, pides uno de la lista.
Es, con diferencia, la opción por defecto, y para la mayoría de integraciones habituales —mover datos de un sistema a otro una vez al día, consultar un listado, dar de alta un registro— es más que suficiente. No necesita nada especial para funcionar, cualquier proveedor la ofrece, y es la más fácil de encontrar quien la entienda si algún día cambias de equipo técnico.
Esa facilidad para encontrar a alguien que la mantenga no es un detalle menor. Si el negocio depende de un proveedor externo para tocar una integración, y ese proveedor desaparece, encontrar un sustituto que entienda REST es cuestión de días. Encontrar uno que entienda una tecnología minoritaria, elegida porque a alguien le pareció más interesante en su momento, puede llevar meses, y ese tiempo se paga en integraciones paradas.
#GraphQL: pedir exactamente lo que hace falta
El problema de REST aparece cuando cada petición trae mucha más información de la que en realidad necesitas, o cuando para reunir todo lo que hace falta en una sola pantalla hay que hacer varias peticiones seguidas, una detrás de otra. Piensa en una app pensada para el móvil que, para mostrar una sola pantalla con el nombre del cliente, su última compra y su dirección de envío, tiene que llamar tres veces al sistema y cada vez recibe de vuelta un paquete de datos mucho más grande de lo que esa pantalla necesita mostrar.
Eso tiene un coste real: más batería del teléfono, más datos de la tarifa del cliente, y una app que se nota más lenta de lo que debería. GraphQL resuelve justo eso: en vez de una carta fija con platos completos, permite pedir exactamente los campos que hacen falta —solo el nombre, solo la fecha de la última compra— en una sola petición, ni un dato de más. Cuesta más montarlo, y por eso solo compensa cuando el problema que resuelve es real: apps con mucho tráfico móvil, pantallas que combinan datos de varias fuentes a la vez.
El coste de montarlo no es solo económico al principio: también es de mantenimiento después. Un equipo tiene que documentar bien qué se puede pedir y entender cómo se combinan las peticiones, y eso exige más experiencia que trabajar con la carta fija de REST. Para un negocio pequeño con una sola app sencilla, ese coste extra raras veces se recupera.
#WebSocket: dejar la línea abierta
Tanto REST como GraphQL funcionan por turnos: preguntas, y te responden. Ninguno de los dos avisa por su cuenta cuando pasa algo nuevo sin que se lo pidas primero. WebSocket es distinto: abre una conexión que se queda activa, como una llamada de teléfono que no se cuelga, y por esa línea abierta el sistema puede avisar en el momento en que ocurre algo, sin que nadie tenga que preguntar.
Es lo que hace posible que un panel de control se actualice solo delante de tus ojos —una cifra de ventas que cambia sin que nadie recargue la página, un contador de aforo que sube en directo— o que un chat de atención al cliente muestre el mensaje nuevo al instante, en vez de cada vez que alguien refresca la pantalla.
Mantener esa línea abierta tiene un coste que no tienen ni REST ni GraphQL: el sistema tiene que sostener miles de conexiones activas a la vez, una por cada persona mirando el panel en ese momento, en lugar de atender peticiones sueltas que se abren y se cierran al instante. Eso exige una infraestructura pensada para ello, y es la razón por la que WebSocket se reserva para los casos donde de verdad hace falta, no para cualquier pantalla que alguien quiera «más viva».
#Los tres, uno al lado del otro
| Qué problema resuelve | Cuándo se nota la diferencia | Señal de que se eligió mal | |
|---|---|---|---|
| REST | Pedir y recibir datos de forma simple y estándar | Casi nunca: es la opción por defecto y suele bastar | Un proyecto sencillo que se complicó sin necesidad usando otra cosa |
| GraphQL | Pedir solo los datos exactos que hacen falta, en una sola petición | Apps móviles con mucho tráfico, pantallas que combinan varias fuentes | Se montó por moda y nadie del equipo sabe mantenerlo |
| WebSocket | Avisar en el momento, sin que nadie pregunte | Paneles en directo, chats, contadores en tiempo real | Un panel «en tiempo real» que en realidad recarga cada pocos segundos por detrás |
#La trampa de elegir el más moderno porque suena mejor
GraphQL y WebSocket resuelven problemas concretos que REST lleva mal, y fuera de esos problemas no mejoran nada. Montar cualquiera de los dos sin tener ese problema añade una pieza más que alguien tiene que mantener, entender y, el día que falle, arreglar. Un negocio con un panel de ventas normal, que se actualiza una vez al minuto y con eso le sobra, no gana nada usando WebSocket salvo complejidad extra y una factura de mantenimiento más alta.
#Cuándo pedir tiempo real de verdad, y cuándo no hace falta
La pregunta que decide no es «qué es lo más avanzado», sino «qué pasa si esta pantalla tarda un minuto en actualizarse en vez de medio segundo». Si la respuesta es «nada grave» —un panel de ventas, un informe de ocupación, un listado de pedidos—, actualizar cada minuto con la opción más simple es la decisión correcta, y pedir tiempo real de verdad solo añadiría coste sin beneficio real. Si la respuesta es «se pierde dinero o se toma una mala decisión en ese minuto» —el control de aforo de un recinto mientras se llena, un chat en directo, una alarma de seguridad—, entonces sí merece la pena pagar la complejidad de dejar la línea abierta. Antes de pedir «tiempo real» en cualquier proyecto, haz esa pregunta primero: casi siempre, la respuesta honesta es que un minuto de retraso no le cuesta nada al negocio.