Estilos de API: REST, GraphQL, gRPC
Los estilos de API son patrones para la comunicación entre sistemas, cada uno diseñado para resolver problemas diferentes. El libro “Learning API Styles” de Lukasz Dynowski y Sam Newman (O’Reilly) analiza en profundidad cuándo usar REST, GraphQL, gRPC, webhooks y otras opciones, mostrando cómo las decisiones arquitectónicas tempranas impactan en costo, latencia y escalabilidad después.
En 30 segundos
- REST es el estándar más popular, simple y cacheable, pero tiene problemas de over/under-fetching
- GraphQL permite que el cliente defina exactamente qué datos necesita, mucho más eficiente para móviles
- gRPC es 10x más rápido que REST usando Protocol Buffers y HTTP/2, ideal para microservicios internos
- Webhooks y WebSockets comunican eventos en tiempo real mediante push en lugar de polling
- La arquitectura moderna mezcla estilos: REST público, gRPC interno, GraphQL para clientes especializados
Los estilos de API son patrones arquitectónicos que definen cómo se comunican los sistemas entre sí. Cada estilo (REST, GraphQL, gRPC, webhooks) tiene ventajas y desventajas específicas según latencia requerida, volumen de requests, complejidad del cliente y capacidades del equipo.
¿Qué son los estilos de API y por qué importan?
Ponele que tenés un proyecto con 200 endpoints REST y de repente tu app móvil se vuelve lenta porque descarga 50 campos cuando necesita solo 5 (over-fetching). Subís a producción, tu iOS app se queja, los usuarios se bajan, gastaste 6 meses en desarrollo y nadie te dijo que quizás existía una opción mejor antes de arrancar.
Eso es el problema que resuelven los estilos de API. No es que REST sea “malo” ni GraphQL sea “revolucionario” (acá viene lo bueno). El tema es que cada patrón fue diseñado para contextos diferentes. SOAP fue para servicios empresariales en 2000, REST ganó porque la web crecía, GraphQL llegó porque los clientes se multiplicaron (web, iOS, Android, smartwatch), y gRPC vino de Google cuando los microservicios empezaron a explotar. Cada uno resuelve problemas reales de su época.
Lo que Dynowski y Newman plantean en su libro es simple pero revolucionador en la práctica: no existe un estilo “mejor”. Existe el estilo correcto para tu caso de uso. Y ese caso de uso depende de quiénes usan tu API (socios públicos, clientes internos, dispositivos móviles, servidores de tu infraestructura), cuántos requests por segundo soportás, cuánta latencia tolerás, y cuánta complejidad tu equipo está dispuesto a mantener.
REST: El estándar web más popular
REST llegó con Roy Fielding en 2000 y se convirtió en el default de internet porque es simple. Usás métodos HTTP (GET, POST, PUT, DELETE), endpoints basados en recursos (/usuarios, /posts, /comentarios), y códigos de estado estándar (200 OK, 404 Not Found, 500 Server Error).
Las ventajas son obvias: cualquiera entiende un GET /usuarios/123. Los caches de HTTP funcionan nativamente. Podés usar cualquier herramienta (curl, Postman, tu navegador). Hay librerías en todos lados. La documentación es directa.
El problema real es que REST asume una relación 1-a-1 entre endpoint y recurso (o recursos). Vos querés el usuario 123 con sus posts y comentarios. Lo que hacés: GET /usuarios/123, GET /usuarios/123/posts, GET /usuarios/123/comentarios. Eso son 3 requests (under-fetching). O tu API te devuelve el usuario con absolutamente todos sus datos relacionados, y tu cliente móvil solo necesita el nombre (over-fetching). Ninguna es gratis. Más contexto en la seguridad en APIs modernas.
Casos de uso ideales: APIs públicas de lectura simple, backend web tradicional, integraciones B2B donde documentación REST es un activo, microservicios acoplados débilmente.
GraphQL: Consultas flexibles y precisas
GraphQL llegó de Facebook en 2012 para resolver exactamente ese problema. En lugar de múltiples endpoints, tenés un único endpoint. En lugar de que el servidor decida qué devuelve, el cliente especifica exactamente qué necesita.
Una consulta GraphQL se ve así:
query { usuario(id: 123) { nombre email posts { titulo contenido } } }
El servidor devuelve solo eso: nombre, email, y los títulos y contenidos de los posts. Nada más. Sin over-fetching, sin under-fetching. Eficiencia pura (si lo implementás bien).
Las ventajas son reales: aplicaciones móviles usan menos ancho de banda. El equipo frontend define su propio contrato de datos, no depende del backend para cada cambio. El desarrollo es más rápido cuando trabajás con clientes diferentes (web quiere datos X, iOS quiere Y, tu smartwatch quiere Z). Ejemplos: Netflix usa GraphQL internamente, Shopify, Airbnb, GitHub.
Las desventajas: GraphQL es complejo de implementar bien. El caching es más difícil (URLs idénticas, payloads diferentes). La curva de aprendizaje es pronunciada. Si metes la pata con las queries, un cliente malicioso puede meter una query monster que se lleva tu servidor. Necesitás depth limiting y query cost analysis.
Casos de uso ideales: aplicaciones móviles complejas, múltiples tipos de clientes, equipos frontend/backend separados geográficamente, cuando la banda de red es crítica.
gRPC: Comunicación de alto rendimiento para microservicios
gRPC es la alternativa que Google creó para comunicación interna entre microservicios. Usa Protocol Buffers (definición de esquemas binarios), HTTP/2 (multiplexing, compresión), y streaming bidireccional.
El resultado: gRPC es 10 veces más rápido que REST en benchmarks (aunque el benchmark es del propio Google, tomalo con pinzas). Latencia ultra-baja, throughput alto, ideal cuando tus microservicios hablan entre sí 10.000 veces por segundo.
El trade-off: gRPC no es legible. No podés curl un endpoint gRPC. Los navegadores no pueden usarlo nativamente (tenés que usar grpc-web). Debugging es más difícil. Los devs necesitan entender Protocol Buffers y async streams. Es complexidad real, no teórica. Para más detalles técnicos, mirá con las herramientas adecuadas.
Casos de uso ideales: microservicios internos, IoT con recursos limitados, aplicaciones de baja latencia (finanzas, gaming), comunicación servidor-servidor de alto volumen.
Webhooks y WebSockets: Comunicación en tiempo real
REST, GraphQL y gRPC son pull-based: el cliente pide, el servidor responde. Los webhooks invierten el modelo: el servidor empuja eventos al cliente (push-based). Tu API dice “cuando suceda X, le voy a hacer un POST a esta URL con los datos”.
WebSockets es diferente: es una conexión persistente bidireccional que permite que servidor y cliente se manden mensajes en cualquier dirección sin latencia.
Webhooks son perfectos para integraciones: Stripe te avisa cuando alguien pagó, GitHub te notifica cuando hay un push, Slack te dice cuando alguien fue mencionado. Costo bajo, escalable. WebSockets son para experiencias en tiempo real: chats, colaboración en vivo (Figma, Google Docs), dashboards en vivo, live notifications.
El problema de WebSockets es que es stateful: necesitás una conexión abierta por cliente. Más caro en infrastructure. Más difícil de debuguear. Webhooks son más simples pero si tu endpoint está caído, el servidor tiene que reintentar (y eso complica la lógica).
Arquitectura híbrida: Combinando estilos según necesidad
El secreto que Netflix reveló es que usan REST públicamente, gRPC internamente y GraphQL para clientes móviles. No es un error, es arquitectura. Cada layer usa lo que le conviene.
Pattern clásico: BFF (Backend for Frontend). Tenés un servidor GraphQL que es cliente de 5 APIs REST internas. El app móvil pide al GraphQL, el GraphQL pide a REST, convierte todo a lo que el cliente necesita. Complejidad centralizada, cliente simple.
Otro patrón: API Gateway. Tenés un proxy que expone REST públicamente, pero internamente rutea a microservicios gRPC. Clientes externos ven un contrato simple, internamente corrés en hypervelocidad.
El punto de Dynowski y Newman es que la decisión no es blanca o negra. Es contextual. Vos mirás tus constraints (latencia, volumen, equipo disponible, cliente type), y armás la combinación que tenga sentido. Complementá con como vimos en nuestra comparativa.
Errores comunes en el diseño de APIs y cómo evitarlos
Inconsistencia de respuestas
Un endpoint devuelve { “user”: { “id”: 1, “name”: “Ariel” } }, otro devuelve { “id”: 1, “nombre”: “Ariel” }. Ojo: tus clientes van a tener que hacer hacks para normalizar respuestas. Documentá el contrato y mantené consistencia.
Mal uso de códigos HTTP
POST a un endpoint que falla pero devuelve 200 OK. O un GET a un recurso que no existe devuelve 500 en lugar de 404. Los clientes confían en que el código HTTP es semántico. Si lo rompés, es un problema.
Falta de versionado
Cambias tu API de REST a GraphQL sin deprecation warning, sin período de transición. Todos los clientes en vivo se rompen. Peor que perder usuarios, es perder confianza. Versioná siempre: v1, v2 en paralelo, deprecation warnings explícitos.
Seguridad débil
Sin autenticación robusta (OAuth 2.0, JWT), sin rate limiting, sin validación de entrada. Tu API es puerta abierta para ataques. Si usas hosting web profesional como el que ofrece donweb.com, aprovechá sus herramientas de seguridad para proteger tus endpoints.
Documentación faltante
Si no documentás, los clientes adivinan. Usá OpenAPI (Swagger), GraphQL introspection automática, o Postman collections. Documentación viva, no estática.
Tabla comparativa: Estilos de API lado a lado
| Estilo | Latencia | Complejidad | Caching | Caso ideal | Desventaja principal |
|---|---|---|---|---|---|
| REST | Media | Baja | Excelente (HTTP nativo) | APIs públicas simples | Over/under-fetching |
| GraphQL | Media | Alta | Difícil (URLs iguales, payloads diferentes) | Múltiples tipos de clientes | Curva de aprendizaje, query cost |
| gRPC | Muy baja | Alta | No aplica (binario) | Microservicios internos | No web-friendly, complexidad |
| Webhooks | Alta (async) | Media | N/A | Integraciones, eventos | Retry logic compleja |
| WebSockets | Muy baja (persistente) | Alta | N/A | Real-time, colaboración | Stateful, caro en scale |
Decisión: Cómo elegir el estilo correcto para tu proyecto
El framework que Dynowski y Newman proponen es simple: respondé estas preguntas.
1. ¿Quiénes son tus clientes? Si es un partner integrador (otra empresa), REST público con documentación clara. Si es tu app móvil, GraphQL te da flexibilidad. Si es server-to-server interno, gRPC.”
2. ¿Cuántas requests por segundo? Si son cientos, REST zafa. Si son decenas de miles, gRPC. Si es traffic bursty (spike de 10k luego nada), Webhooks + queue es más barato.
3. ¿Latencia crítica? Financiero, gaming, trading: gRPC. News, redes sociales: REST. Chat: WebSockets.
4. ¿Equipo disponible? Startup junior: REST. Equipo senior con experiencia en microservicios: gRPC. Equipo dividido frontend/backend: GraphQL. Ya lo cubrimos antes en en arquitecturas web modernas.
5. ¿Cuántos clientes diferentes? Uno (web): REST. Varios (web, iOS, Android, smartwatch, partner): GraphQL o BFF.
La respuesta es la intersección de todas esas variables. No es una ecuación exacta. Es juicio arquitectónico.
Preguntas Frecuentes
¿Cuáles son los diferentes estilos de APIs que existen?
Los principales son REST (basado en HTTP estándar), GraphQL (query language flexible), gRPC (RPC binario de alto rendimiento), SOAP (protocolo XML empresarial, legacy), Webhooks (push de eventos), WebSockets (conexión persistente bidireccional) y RPC clásico (XML-RPC, JSON-RPC). Cada uno resuelve problemas específicos.
¿Cuándo debo usar GraphQL en lugar de REST?
Cuando tenés múltiples tipos de clientes con necesidades de datos diferentes (web, móvil, smartwatch), cuando la banda de red es crítica, o cuando tu equipo frontend prefiere definir su propio contrato de datos sin esperar cambios al servidor. Si es una API simple con un único cliente, REST es más ligero.
¿Qué ventajas tiene gRPC sobre REST en microservicios?
gRPC es 10 veces más rápido porque usa HTTP/2 (multiplexing), compresión, y serialización binaria (Protocol Buffers) en lugar de JSON. La latencia es ultra-baja. Pero solo aplica para comunicación servidor-a-servidor interno. No lo usés para APIs públicas.
¿Cómo elegir el estilo de API adecuado para mi proyecto?
Respondé: ¿quiénes son mis clientes? ¿Cuántos requests por segundo? ¿Latencia crítica? ¿Capacidades del equipo? ¿Cuántos tipos de clientes? La intersección de esas respuestas te da el estilo. No existe uno “mejor”, solo el correcto para tu contexto.
¿Qué diferencia hay entre webhooks y polling?
Polling es que el cliente pregunta constantemente “¿hay novedades?” (pull). Webhooks es que el servidor avisa cuando hay novedades (push). Webhooks son más eficientes en recursos, pero requieren que el servidor sepa dónde enviar la notificación. Polling es más simple de implementar pero consume más banda.
Conclusión
El libro “Learning API Styles” de Dynowski y Newman no es una receta. Es un mapa mental. Los estilos de API no son buenos ni malos, son opciones con trade-offs. El arquitecto que entiende esos trade-offs, que puede responder “para este caso uso gRPC interno y REST público”, es el que construye sistemas que escalan.
En 2026, es obvio que un proyecto serio mezcla estilos. Frontend team usa GraphQL, microservicios hablan gRPC, partners externos ven REST, webhooks notifican eventos, WebSockets dan real-time. La pregunta no es “¿usamos GraphQL o REST?”. La pregunta es “¿dónde cada uno agrega valor específico?”.
Si estás diseñando una API, no copies lo que hace Google o Netflix ciegamente. Respondé las preguntas correctas, mirá tus constraints reales, y elegí con criterio. Eso es lo que este libro enseña.
