REST vs GraphQL vs gRPC vs SOAP: ¿cómo elegís en la práctica?

#Cuatro apuestas distintas sobre dónde vive la fricción

Cada paradigma de API hace una apuesta sobre dónde conviene poner el dolor de un sistema distribuido: en la cantidad de idas y vueltas, en la forma del payload, en la rigidez del esquema, o en la ceremonia del contrato. REST? apuesta a que la interfaz uniforme de HTTP y su semántica de cacheo valen más que traer exactamente los campos que necesitás. GraphQL? apuesta lo contrario: que la forma exacta de datos que pide el cliente importa más que un cacheo uniforme, así que colapsa muchas llamadas REST en una sola query a costa de un servidor más complejo. gRPC apuesta a que las llamadas internas, de alto throughput, entre servicios deberían pagar el costo de un formato binario y stubs generados desde el principio, a cambio de velocidad y streaming. SOAP apuesta a que un contrato verificable por máquina y fuertemente tipado (WSDL, XML Schema) vale la verbosidad, porque el costo de una integración mal alineada en banca o salud es más alto que el costo de un sobre más pesado.

Ninguno es "mejor" en términos absolutos — cada uno responde a una ansiedad distinta. Una API pública con miles de consumidores impredecibles quiere la cacheabilidad de REST y su enorme ecosistema de herramientas genéricas. Una app móvil con conexión lenta y medida quiere la capacidad de GraphQL de pedir exactamente los diecisiete campos que necesita la pantalla, en vez de seis respuestas REST con datos de más. Una flota de microservicios internos haciendo cien mil llamadas por segundo quiere el framing binario de gRPC y el multiplexado de HTTP/2. Una integración empresarial con un banco quiere el contrato rígido y generado de SOAP y sus estándares incorporados para transacciones y seguridad (WS-Transaction, WS-Security) que REST nunca terminó de reemplazar.

#Lado a lado

#Cómo se ve la petición, en la práctica

#Cómo elegir, en la práctica

• Si tus consumidores son desconocidos, numerosos y van a construir sobre tu API durante años — REST. El ecosistema (caches, proxies, gateways, monitoreo) ya lo entiende.
• Si controlás ambos extremos y tu cuello de botella es que el cliente arma muchas vistas distintas de los mismos datos (un dashboard, una app móvil, una capa pública que alimenta una SPA) — GraphQL, normalmente como gateway delante de servicios REST o gRPC, no como reemplazo total.
• Si ambos extremos son servicios que controlás, la latencia y el throughput importan, y querés contratos verificados por el compilador entre distintos lenguajes — gRPC.
• Si estás integrando con un sistema empresarial o gubernamental que ya habla SOAP y exige WS-Security o transacciones distribuidas — SOAP, porque ese ecosistema nunca fue realmente JSON contra XML, sino los estándares construidos sobre el sobre.

🧠 Check your understanding
0/3 · 0/3 answered
1. Un equipo está construyendo una API pública con la que miles de terceros desconocidos van a integrarse durante los próximos cinco años. ¿Qué paradigma les da más herramientas listas para usar (proxies, caches, gateways)?
RESTgRPCSOAPGraphQL
2. ¿Por qué un resolver ingenuo de GraphQL para los pedidos de una lista de usuarios es propenso al problema N+1?
GraphQL requiere parsear XML en cada campogRPC no soporta paginaciónGraphQL obliga a correr todas las queries sobre UDPCada campo se resuelve de forma independiente, así que resolver 'orders' una vez por usuario en la lista dispara una consulta por usuario si no se hace batching
3. ¿Cuál es la razón principal por la que gRPC no es una buena opción para una API pública consumida directamente desde el navegador, sin intermediarios?
Protobuf no puede representar objetos anidadosNo puede usar HTTP/2gRPC no tiene concepto de cliente generadoLos navegadores no pueden generar nativamente el framing que necesita gRPC, así que normalmente requiere grpc-web y un proxy