REST vs GraphQL vs gRPC — ¿cuándo elegirías cada uno?

Question

IT Interview Practice · Accepted Answer

Estos son tres paradigmas de API diferentes, cada uno optimizado para restricciones distintas. No hay un ganador universal — la elección correcta depende del **consumidor, la forma de los datos, y la red**.

## Los tres de un vistazo

```text
           REST                 GraphQL              gRPC
Estilo     recursos + HTTP      un query graph       RPC (llamar métodos)
Transporte HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binario)
Fetching   endpoints fijos      el client elige      métodos fijos
Schema     opcional (OpenAPI)   fuerte, tipado       fuerte, .proto
Browser    nativo, cacheable    necesita client lib  limitado (necesita proxy)
```

## REST

Orientado a recursos sobre HTTP plano. **Elígelo** para APIs públicas, servicios CRUD, y cualquier cosa que se beneficie del HTTP caching, la ubicuidad y la simplicidad. Sus debilidades son el **over-fetching** (recibes el `/users/42` entero aunque solo necesites un field) y el **under-fetching** (el problema `N+1`: obtener un user, y luego iterar para obtener cada order).

```http
GET /users/42            → el user entero
GET /users/42/orders     → un segundo round trip
```

## GraphQL

Un único endpoint donde el **client especifica exactamente lo que quiere** en una query, resolviendo el over/under-fetching. **Elígelo** para frontends ricos (especialmente móvil, donde los round trips son costosos) y cuando muchos clients necesitan formas distintas de los mismos datos.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← un round trip, fields exactos
```
Compromisos: el HTTP caching es más difícil (todo es un `POST` a `/graphql`), y un resolver ingenuo puede esconder queries `N+1` costosas a la base de datos.

## gRPC

RPC contract-first usando **Protobuf** sobre **HTTP/2**. Binario y multiplexado, así que es rápido y compacto con soporte de streaming. **Elígelo** para comunicación **service-to-service interna** en un backend de microservicios donde el rendimiento y el tipado estricto importan. Debilidad: soporte de browser pobre (necesita un proxy como grpc-web) y no es legible por humanos.

## Cómo elegir

```text
API pública, CRUD, caching, amplio alcance   → REST
Necesidades de datos de frontend complejas/variadas → GraphQL
Microservicios internos de alto rendimiento  → gRPC
(Los sistemas reales los mezclan: REST/GraphQL en el borde, gRPC entre servicios.)
```

## Por qué es importante

A nivel senior, a los entrevistadores les importan menos las definiciones y más si puedes **justificar una elección frente a restricciones** — esta pregunta es realmente "¿puedes emparejar una tecnología con un problema en lugar de perseguir el hype?". Las respuestas más fuertes se anclan en el dolor que cada uno resuelve: GraphQL existe para matar el over/under-fetching de frontends exigentes, gRPC existe para hacer las llamadas a servicios internos rápidas y con tipado estricto, y REST sigue siendo el valor por defecto porque el HTTP caching, el tooling y la familiaridad universal son ventajas prácticas enormes para APIs públicas y de estilo CRUD. Crucialmente, un ingeniero senior nota que **no es lo uno o lo otro** — una arquitectura común es REST o GraphQL en el borde público con gRPC entre los microservicios del backend — y nombra los compromisos concretos (los riesgos de caching y `N+1` de GraphQL, la débil historia de browser de gRPC). Ese razonamiento sobre encaje y coste, no la capacidad de recitar características, es la señal.

Los tres de un vistazo

REST

GraphQL

gRPC

Cómo elegir

Por qué es importante

Preguntas relacionadas