La web solía ser un intercambio de cartas cortés: usted escribe una solicitud, recibe una respuesta. Luego las máquinas empezaron a responder a mitad de frase, pidiendo herramientas, transmitiendo pensamientos, cantando paquetes de voz sobre UDP. Elegir un estilo de API ahora se trata menos de ideología y más de coreografía: quién lidera, quién sigue, quién improvisa, y cómo mantener el ritmo cuando la banda es mitad humana, mitad transformer.

TL;DR

  • REST permanece como la columna vertebral pública, cacheable y amigable con CDN. Combínelo con OpenAPI y (para IA) salidas estructuradas para convertir los modelos en máquinas predecibles.
  • GraphQL brilla cuando las UIs de producto necesitan cortes flexibles de datos; use APQ y (donde sea necesario) subscriptions sobre SSE/WebSocket.
  • gRPC gobierna las llamadas servicio-a-servicio: contratos sólidos, streaming, deadlines y semánticas de error claras sobre HTTP/2; use Connect/gRPC-Web en el borde del navegador.
  • tRPC es la opción pragmática para un equipo TypeScript-en-todas-partes que envía apps internas/front-end-a-backend rápidamente; exporte OpenAPI si externos deben consumirlo.
  • SSE es el camino más simple para streaming de tokens desde LLMs; ampliamente usado por stacks de OpenAI/Anthropic. WebSocket es para interacción genuinamente bidireccional, de baja latencia (edición colaborativa, multijugador, agentes "realtime" de modelos).
A pequeña escala, sesgo hacia REST + SSE o tRPC + SSE. A escala media, GraphQL para superficies de producto, gRPC para internos. A gran escala, construya un mesh mixto: REST en el perímetro, GraphQL para agregación, gRPC para este-oeste, SSE/WS para tiempo real, con contratos tipados y gateways como puntos de política.

La nueva restricción: IA en la ruta de solicitud

Tres comportamientos dominan las arquitecturas de 2025:

  1. Respuestas en streaming. Los usuarios esperan que las palabras (y el audio) lleguen a mitad del pensamiento. La mayoría de las APIs de LLM importantes transmiten vía Server-Sent Events (SSE); los agentes de voz a menudo usan WebRTC/WebSocket para medios full-duplex. Su transporte debe manejar resultados parciales, contrapresión y cancelación.
  1. Uso de herramientas / function calling. Los modelos emiten llamadas tipadas; usted las ejecuta y devuelve los resultados. Las salidas estructuradas respaldadas por JSON Schema y los esquemas de herramientas hacen esto robusto.
  1. SLAs estrictos entre servicios. Los pipelines de LLM se ramifican: embeddings aquí, retrieval allá, re-ranking en otro lugar. Los deadlines/timeouts y códigos de error tipados mantienen las cadenas honestas—aquí es donde la semántica de gRPC ayuda.

Mantenga estos tres en mente; son el metrónomo para el resto de la partitura.

Dimensionamiento del proyecto (sea preciso, no grandioso)

  • Pequeño: 1–3 desarrolladores, ≤ 9 meses, ≤ ~10k LOC, una UI + un par de servicios, sin API pública.
  • Mediano: 3–12 desarrolladores, 9–36 meses, 10k–75k LOC, múltiples clientes, algunos servicios internos, quizás integraciones de socios.
  • Grande: 12–50+ desarrolladores, multi-año, 75k–250k+ LOC, políglota, APIs/SDKs públicos, regulado o crítico para ingresos.

La mayoría de los proyectos "grandes" son en realidad medianos; la inflación de complejidad es real. Elija el estilo más simple que aún escale hacia su horizonte.

REST: el perímetro duradero

Cuando brilla: APIs públicas, lecturas cacheables, amplia compatibilidad de clientes, governance y vidas largas. Lo que le da:
  • Semántica HTTP & caching: verbos, códigos de estado, negociación de contenido; ganancias de CDN/edge en GET con RFC 9110/9111.
  • Observabilidad & política: gateways maduros, rate limits, flujos OAuth, reintentos.
Giro de la era IA:
  • Salidas estructuradas: exponga endpoints estilo "function-calling" con contratos JSON Schema para que sus clientes de modelo alcancen formas determinísticas. (OpenAI/Azure envían salidas estructuradas de primera clase.)
  • Tokens en streaming: mantenga la solicitud como REST clásico, pero devuelva text/event-stream y empuje deltas vía SSE; este es el patrón de facto entre proveedores.
Use para:
  • Pequeño: CRUD + un endpoint SSE /chat/stream.
  • Mediano: APIs de socios; webhooks públicos; recursos pesados en caché.
  • Grande: el contrato con el que quiere que terceros vivan una década desde ahora.
Patrones REST que necesitará:
  • JSON Patch (RFC 6902) & JSON Merge Patch (RFC 7386): Reduzca payloads y conflictos para actualizaciones de modelo/config; esencial cuando agentes IA ajustan recursos frecuentemente.
  • Hypermedia/Formatos (JSON:API, HAL, OData): Estandarice formas, paginación y enlaces para que agentes y herramientas no tengan que reaprender las peculiaridades de cada API. Especialmente útil para "function calling" de IA contra muchos servicios.

GraphQL: datos con forma de producto, un viaje de ida y vuelta

Cuando brilla: UIs complejas que necesitan cortes a través de dominios; menos viajes de ida y vuelta; evolución gobernada por esquema. Lo que le da:
  • Un esquema tipado que el cliente consulta flexiblemente; no atado al almacenamiento.
  • Subscriptions y campos en streaming vía WebSocket o cada vez más GraphQL sobre SSE.
Giro de la era IA:
  • APQ (Automatic Persisted Queries) para habilitar GET + caché en el edge; los modelos pueden entrenarse para elegir de un catálogo de operaciones en lista blanca (menos jailbreak, más guardrails).
  • Elección de transporte: para resultados incrementales (@defer, subscriptions), SSE es simple y nativo de HTTP; mantenga WebSocket donde realmente necesite interacción duplex.
Use para:
  • Pequeño: solo si tiene múltiples clientes con vistas divergentes; de lo contrario REST es más rápido para enviar.
  • Mediano: capa de agregación de UI; unir microservicios; subscriptions para widgets en vivo.
  • Grande: supergrafos/federation con APQ, caching y política en el router.

gRPC: la columna vertebral de su service mesh

Cuando brilla: llamadas inter-servicio con contratos estrictos, streaming y SLAs ajustados. Lo que le da:
  • Esquemas Protocol Buffers y clientes generados; transporte HTTP/2 con multiplexación; streaming unario + cliente/servidor/bidi.
  • Deadlines, cancelación, códigos de estado incorporados—crucial cuando un pipeline de LLM encadena varios saltos.
Realidad del navegador:
  • gRPC nativo sobre HTTP/2 no es directamente amigable con el navegador; use gRPC-Web o un servidor Connect para hacer puente (y aún puede transmitir).
Giro de la era IA:
  • Perfecto para backends de herramientas (retrievers, buscadores vectoriales, rerankers) donde necesita deadlines y errores tipados para mantener la orquesta unida bajo presupuestos de latencia.
Use para:
  • Pequeño: generalmente excesivo a menos que ya esté en tierra de Proto.
  • Mediano: servicios internos y planos de datos.
  • Grande: el protocolo este-oeste por defecto; exponga REST/GraphQL en el edge.

tRPC: velocidad TypeScript de extremo a extremo

Cuando brilla: un equipo, TypeScript en ambos lados, quiere tipos sin maquinaria extra. Lo que le da:
  • Tipos inferidos del servidor al cliente; boilerplate mínimo; HTTP bajo el capó.
Advertencias:
  • No es políglota; acoplamiento estrecho a TS; no ideal como API pública a menos que exporte OpenAPI (existen plugins de la comunidad).
Giro de la era IA:
  • Los tipos de extremo a extremo son catnip para copilotos: cambie la forma del servidor, el compilador (y el modelo) guía la refactorización. Para consumidores de modelos externos, publique OpenAPI para que stacks no-TS puedan interoperar.
Use para:
  • Pequeño: camino más rápido para equipos TS (ej., apps Next.js).
  • Mediano: dashboards/devtools internos; gradúe a REST/GraphQL cuando lleguen socios.
  • Grande: raramente; refleje contratos en OpenAPI/GraphQL si lo mantiene.

SSE: el caballo de batalla subestimado del UX de IA

Qué es:
  • Una única conexión HTTP transmitiendo text/event-stream al EventSource del navegador. Unidireccional servidor → cliente; auto-reconexión; amigable con proxies.
Por qué la IA lo ama:
  • El streaming de tokens es natural en SSE, y muchos proveedores lo documentan explícitamente (incluyendo en clouds gestionados).
Use para:
  • Pequeño/Mediano/Grande: cuando necesite salidas incrementales sin charla bidireccional (chat, logs, eventos de progreso). Reserve WS para duplex real.
Variante: HTTP streaming con NDJSON (JSON Lines):
  • Streams servidor → cliente baratos y debuggeables (y un buen ajuste para output token-por-token de LLM). Combine con SSE cuando no necesite duplex completo.

WebSocket: cuando realmente necesita bidireccional

Qué es:
  • Un canal full-duplex definido por RFC 6455, con APIs de navegador en MDN; genial para apps interactivas y protocolos personalizados.
Giro de la era IA:
  • Para agentes de voz/visión o herramientas colaborativas, terminará con WebSocket o WebRTC (OpenAI/Azure soportan ambos caminos en realtime).
Use para:
  • Pequeño: chats, cursores, pizarras que necesitan eventos cliente→servidor.
  • Mediano/Grande: collab con estado o canales de control en tiempo real; de lo contrario prefiera SSE.

Adiciones modernas: la capa de streaming y eventos

WebTransport (HTTP/3/QUIC)

Qué es: Streams bidireccionales y datagramas no confiables hacia un servidor, sin bloqueo head-of-line. Uso en la era IA: Ideal para streaming de tokens y telemetría de baja latencia cuando WebSockets chocan con problemas de proxy o multiplexación. Útil para streams de tokens LLM, control de modelo en vivo y actualizaciones de UI multi-stream. Use para: Mediano/Grande cuando necesite transporte multi-stream de baja latencia real y pueda controlar tanto cliente como servidor.

WebRTC Data Channels

Qué es: Datos peer-to-peer, confiables o de confiabilidad parcial; perfecto para agentes de voz/visión, multijugador, o herramientas IA local-first. Uso en la era IA: WebRTC es cómo las nuevas APIs de IA en tiempo real entregan voice-in/voice-out. También genial para inferencia IA distribuida (enrutamiento de modelos peer-to-peer). Use para: Pequeño/Mediano/Grande agentes de voz, edición colaborativa, multijugador, o cualquier escenario donde peer-to-peer reduzca costos de servidor.

Web Push + Notifications API

Qué es: Para re-engagement y empujones out-of-band (ej., "su trabajo batch LLM de larga duración terminó"). Funciona incluso cuando la app no está abierta. Use para: Mediano/Grande notificaciones de trabajos en segundo plano, alertas de finalización de entrenamiento de modelos.

Mensajería para servicios, agentes y planos de datos

MQTT (incl. MQTT sobre WebSockets)

Qué es: Pub/sub ultra-ligero; excelente para dispositivos IoT que alimentan IA en el edge o se suscriben a salidas de modelos. Amigable con navegadores vía WebSockets. Use para: Pequeño/Mediano deployments IoT + IA en edge; Grande cuando necesite millones de dispositivos conectados ligeros.

NATS (+ JetStream)

Qué es: Mensajería simple y muy rápida con streams durables opcionales y patrones exactly-once; buena columna vertebral para microservicios más agentes IA que necesitan request/reply y pub/sub. Use para: Mediano bus de eventos interno; Grande como columna vertebral de service mesh cuando necesite simplicidad sobre la complejidad de Kafka.

Apache Kafka (Event Streaming)

Qué es: Logs de eventos durables y ordenados para pipelines de alto throughput; genial para telemetría de modelos, feature stores y emitir/consumir eventos IA a escala. Use para: Grande arquitecturas orientadas a eventos, ML feature stores, logs de auditoría, pipelines CDC alimentando modelos IA.

AMQP 1.0

Qué es: Mensajería enterprise abierta e interoperable; enrutamiento robusto, transacciones y confiabilidad. Útil donde los eventos IA deben atravesar sistemas heterogéneos (bancos, gobierno, aerolíneas). Use para: Grande industrias reguladas que necesitan entrega garantizada y semántica transaccional.

CloudEvents (CNCF)

Qué es: Un sobre común para eventos a través de transportes (HTTP, Kafka, NATS). Ayuda a estandarizar payloads de eventos IA a través de su infraestructura. Use para: Mediano/Grande cuando esté ejecutando arquitecturas de eventos multi-transporte y necesite interop.

AsyncAPI

Qué es: El OpenAPI de sistemas de eventos; documente y gobierne sus APIs de streaming/mensajería (Kafka, MQTT, NATS, AMQP). Use para: Mediano/Grande governance, generación de SDK de cliente, catálogos de API para sistemas orientados a eventos.

Alternativas RPC & puentes

Connect RPC (por Buf)

Qué es: Un hermano pragmático y amigable con HTTP/1.1 de gRPC con JSON + Protobuf de primera clase, CORS simple y buena DX—útil para web + móvil hablando con los mismos backends IA. Use para: Pequeño/Mediano cuando quiera semántica gRPC sin el dolor de navegador/proxy; Grande como alternativa más simple a gRPC-Web.

gRPC-JSON Transcoding (Envoy)

Qué es: Exponga REST/JSON sobre sus backends gRPC para que toolchains IA y clientes low-code puedan llamarlos fácilmente. Use para: Mediano/Grande cuando quiera mantener gRPC internamente pero exponer REST externamente.

Cap'n Proto / Thrift

Qué es: Nicho pero potente: RPC zero-copy basado en capabilities (Cap'n Proto) o RPC IDL-first maduro (Thrift). Use para: Grande latencia súper baja entre microservicios IA donde los nanosegundos importan.

Protocolos específicos de IA que vale la pena conocer

Model Context Protocol (MCP)

Qué es: Un protocolo abierto basado en JSON-RPC para conectar modelos con herramientas, datos e IDEs. Si su artículo cubre "IA llamando sus APIs", MCP es la historia neutral de vendor. Use para: Pequeño/Mediano/Grande cuando construya sistemas de agentes IA que necesiten conectores estandarizados de herramientas/datos.

Salidas Estructuradas / respuestas restringidas por JSON Schema

Qué es: Trate a los LLMs como APIs bien tipadas; crucial para uso de herramientas y automatización segura. Use para: Todos los tamaños cuando exponga APIs a agentes IA—aplique esquemas para prevenir campos alucinados.

IA Realtime sobre WebRTC/WebSocket

Qué es: Muchos vendors de LLM ahora ofrecen APIs WebRTC/WebSocket realtime para agentes de voz/visión. Use para: Mediano/Grande asistentes de voz, transcripción en vivo, análisis de visión con resultados en streaming.

Patrones de puente que vale la pena conocer (2025)

  • Connect RPC: un solo codebase que habla gRPC, gRPC-Web, y su propio protocolo amigable con HTTP (JSON o Protobuf; streaming también). Es una forma práctica de exponer el mismo servicio a navegadores y backends sin gimnasia de Envoy.
  • GraphQL sobre SSE: muchos servidores ahora implementan SSE para subscriptions (ops más simples, nativo de HTTP). Mantenga WS donde necesite duplex.
  • APQ para GraphQL: habilite GET + hashes para caching en edge y listas blancas.

Guía de decisión por tamaño de proyecto

Pequeño (1–3 desarrolladores, ≤9 meses)

Por defecto:
  • REST + SSE (OpenAPI + salidas estructuradas; un endpoint de streaming).
  • ¿TS full-stack? tRPC + SSE para velocidad; exporte OpenAPI si alguien fuera de su repo debe llamarle.
Evite:
  • GraphQL a menos que realmente tenga múltiples clientes divergentes.
  • gRPC a menos que ya posea Proto.

Mediano (3–12 desarrolladores, 9–36 meses)

Front-ends:
  • GraphQL para flexibilidad de UI; active APQ; use SSE para subscriptions/streaming.
Internos:
  • gRPC entre servicios; establezca deadlines; mapee errores a códigos de estado.
  • NATS o Kafka para bus de eventos asíncrono.
Tiempo real:
  • SSE para streams de tokens.
  • WebSocket solo si los clientes deben enviar eventos en vivo.
Governance:
  • AsyncAPI si tiene servicios orientados a eventos.
  • CloudEvents para estandarización de sobres de eventos.

Grande (12–50+, multi-año)

Perímetro:
  • REST (versionado, cacheable) con salidas estructuradas para clientes IA; publique SDKs.
Agregación:
  • Supergrafo GraphQL con APQ; subscriptions sobre SSE donde sea posible, WS donde sea necesario.
Mesh:
  • gRPC este-oeste (streaming donde ayude); haga puente a navegadores con Connect/gRPC-Web.
  • Kafka como columna vertebral de eventos para pipelines ML, feature stores, logs de auditoría.
Agentes realtime:
  • Canales de control WebRTC/WS; SSE para fallbacks de stream de texto.
Governance:
  • API Extractor para superficie pública TypeScript.
  • AsyncAPI para catálogos de eventos.
  • CloudEvents para interop de eventos cross-transport.

Trampas comunes (y cómo la IA cambia las matemáticas)

  1. Usar WebSocket "solo porque es realtime". Si el cliente raramente habla de vuelta, elija SSE; es más simple, más amigable con CDN/proxy, y se alinea con flujos de tokens LLM.
  1. GraphQL sin una historia de caché. Active APQ y considere caching de respuestas donde la semántica lo permita; de lo contrario empujará todo a cachés de cliente y se preguntará por qué el edge está inactivo.
  1. tRPC público. Genial dentro de un monorepo TS; para socios, genere OpenAPI (o proporcione REST/GraphQL) para que clientes no-TS y agentes IA puedan integrarse sanamente.
  1. Ignorar deadlines en pipelines LLM. gRPC (o Connect) hace timeouts/cancelación de primera clase; propáguelos o vea la latencia de cola explotar.
  1. Mezclar demasiados transportes sin contratos. Elija 2-3 estilos primarios y haga puente cuidadosamente. Use OpenAPI, AsyncAPI y Protobuf para mantener la cordura.

Selector rápido (centrado en IA)

  • "Necesito una API pública que los socios puedan cachear en el edge, y mis clientes IA necesitan esquemas JSON." → REST + OpenAPI + Salidas Estructuradas; SSE para streaming.
  • "Mi UI de producto extrae formas a medida a través de varios backends." → GraphQL (+ APQ, subscriptions SSE).
  • "Este es un plano de datos interno, sensible a latencia con fan-out y reintentos." → gRPC (deadlines, códigos de estado, streaming).
  • "Somos un equipo TS enviando una webapp rápido." → tRPC (exporte OpenAPI si alguien más va a llamarlo).
  • "Es un chat/consola/stream de respuestas." → SSE.
  • "Es colaborativo y bidireccional o voz." → WebSocket/WebRTC.
  • "Necesitamos microservicios orientados a eventos a escala." → Kafka (grande), NATS (mediano), con docs AsyncAPI y sobres CloudEvents.
  • "Agentes IA necesitan llamar nuestras herramientas internas." → REST con JSON Schema + MCP, o gRPC con definiciones de herramientas estructuradas.

Conclusión: La orquesta mantiene el ritmo

En 2025, elegir transporte API no es una única decisión—es orquestar un stack donde diferentes instrumentos tocan diferentes partes.

REST ancla su superficie pública. GraphQL agrega para UIs de producto. gRPC conecta servicios bajo SLA. SSE transmite tokens desde modelos. WebSocket maneja duplex real. Kafka/NATS median eventos. CloudEvents estandariza sobres. AsyncAPI documenta los flujos.

Los equipos que envían más rápido no son los que eligen "el mejor" transporte. Son los que:
  • Dimensionan su proyecto honestamente (Pequeño/Mediano/Grande)
  • Eligen 2-3 estilos primarios y hacen puente entre ellos limpiamente
  • Tratan streaming y llamadas de herramientas como preocupaciones de primera clase
  • Usan esquemas (OpenAPI, Protobuf, JSON Schema, AsyncAPI) para mantener a humanos e IA honestos

La IA no hizo obsoleto a REST. Hizo arquitecturas híbridas obligatorias. Las máquinas están en el loop ahora, y necesitan contratos en los que puedan confiar.

Envíe la coreografía. Mantenga el ritmo. Deje que la banda toque.

---

Sobre el autor: Odd-Arild Meling ha construido capas API para switches de telecomunicaciones, pasarelas de pago, juegos multijugador y agentes impulsados por LLM. Ha debuggeado deadlines de gRPC a las 3 AM, celebrado lógica de reconexión SSE que salvó el Black Friday, y visto conexiones WebSocket multiplicarse de docenas a millones. Actualmente arquitectando sistemas edge-first en Gothar donde REST, GraphQL, gRPC y SSE todos se envían a producción—porque la realidad no elige favoritos.