REST vs GraphQL vs gRPC: ¿Qué Protocolo API Deberías Elegir?

En resumen

Usa REST para APIs públicas y operaciones CRUD simples. Usa GraphQL cuando los clientes necesiten una obtención de datos flexible y quieras reducir la sobre-obtención (over-fetching). Usa gRPC para la comunicación de microservicios de alto rendimiento. La Modern PetstoreAPI implementa los tres protocolos, permitiéndote elegir la herramienta adecuada para cada caso de uso.

Introducción

Estás construyendo una API. ¿Deberías usar REST, GraphQL o gRPC? Cada protocolo tiene defensores apasionados que afirman que el suyo es el mejor. La verdad: todos son buenos en cosas diferentes.

REST es universal y simple. GraphQL da a los clientes control sobre la obtención de datos. gRPC es rápido y eficiente para servicios internos. La mejor elección depende de tu caso de uso, no de qué protocolo es "mejor".

La mayoría de las APIs eligen un protocolo y se apegan a él. Modern PetstoreAPI adopta un enfoque diferente: implementa REST, GraphQL y gRPC, mostrando cómo la misma API de tienda de mascotas funciona en los tres protocolos.

💡

Si estás construyendo o probando APIs, Apidog soporta REST, GraphQL y gRPC. Puedes probar los tres protocolos en una sola herramienta, comparar respuestas y asegurar la consistencia entre las implementaciones.

botón

En esta guía, aprenderás las fortalezas y debilidades de cada protocolo, verás ejemplos reales de Modern PetstoreAPI y descubrirás cómo elegir el protocolo adecuado para tus necesidades.

REST: El estándar universal

REST (Representational State Transfer) es el protocolo de API más común.

Cómo funciona REST

Los recursos se acceden a través de URLs con métodos HTTP:

GET    /pets           - Listar mascotas
POST   /pets           - Crear mascota
GET    /pets/{id}      - Obtener mascota
PUT    /pets/{id}      - Actualizar mascota
DELETE /pets/{id}      - Eliminar mascota

Ejemplo de solicitud:

GET https://petstoreapi.com/v1/pets/019b4132-70aa-764f-b315-e2803d882a24

Ejemplo de respuesta:

{
  "id": "019b4132-70aa-764f-b315-e2803d882a24",
  "name": "Fluffy",
  "species": "CAT",
  "status": "AVAILABLE",
  "price": 299.99
}

Fortalezas de REST

1. Compatibilidad universal

Cada lenguaje de programación tiene bibliotecas HTTP. Navegadores, curl, Postman, todo funciona con REST.

2. Fácil de entender

Las URLs representan recursos. Los métodos HTTP representan acciones. El modelo mental es sencillo.

3. Cacheable

El almacenamiento en caché HTTP funciona de forma predeterminada. Las solicitudes GET pueden ser almacenadas en caché por navegadores, CDNs y proxies.

4. Sin estado (Stateless)

Cada solicitud es independiente. No hay estado de sesión en el servidor.

5. Excelentes herramientas

Especificaciones OpenAPI, Swagger UI, herramientas de prueba de API: REST tiene el mejor ecosistema.

Debilidades de REST

1. Sobre-obtención (Over-fetching)

Obtienes todos los campos incluso si solo necesitas uno:

// Solo necesitas el nombre, pero obtienes todo
{
  "id": "019b4132-70aa-764f-b315-e2803d882a24",
  "name": "Fluffy",
  "species": "CAT",
  "status": "AVAILABLE",
  "price": 299.99,
  "description": "...",
  "images": [...],
  "vaccinations": [...]
}

2. Sub-obtención (Under-fetching) (problema N+1)

Para obtener una mascota y sus pedidos, necesitas múltiples solicitudes:

GET /pets/123           # Obtener mascota
GET /pets/123/orders    # Obtener pedidos
GET /orders/456/items   # Obtener ítems del pedido

3. Complejidad de versionado

Los cambios que rompen la compatibilidad requieren nuevas versiones de API (/v1, /v2).

4. Sin actualizaciones en tiempo real

REST es solicitud-respuesta. Para datos en tiempo real, necesitas sondeo (polling) o WebSockets.

Cuándo usar REST

APIs públicas (máxima compatibilidad)
Operaciones CRUD simples
Cuando el almacenamiento en caché es importante
Cuando necesitas un amplio soporte de herramientas
Aplicaciones móviles con necesidades de datos predecibles

Implementación REST de Modern PetstoreAPI

GraphQL: Obtención de datos flexible

GraphQL permite a los clientes especificar exactamente qué datos necesitan.

Cómo funciona GraphQL

Un único endpoint con un lenguaje de consulta:

query {
  pet(id: "019b4132-70aa-764f-b315-e2803d882a24") {
    name
    species
    orders {
      id
      total
      items {
        product
        quantity
      }
    }
  }
}

Respuesta:

{
  "data": {
    "pet": {
      "name": "Fluffy",
      "species": "CAT",
      "orders": [
        {
          "id": "order-123",
          "total": 49.99,
          "items": [
            {"product": "Comida para gatos", "quantity": 2}
          ]
        }
      ]
    }
  }
}

Fortalezas de GraphQL

1. Sin sobre-obtención (no over-fetching)

Los clientes solicitan solo los campos que necesitan:

query {
  pet(id: "019b4132-70aa-764f-b315-e2803d882a24") {
    name  # Solo obtiene el nombre
  }
}

2. Sin sub-obtención (no under-fetching)

Obtén datos relacionados en una sola solicitud:

query {
  pet(id: "019b4132-70aa-764f-b315-e2803d882a24") {
    name
    orders {
      items {
        product
      }
    }
  }
}

Sin problema N+1.

3. Tipado fuerte

Los esquemas de GraphQL están fuertemente tipados. Los clientes saben exactamente qué está disponible.

4. Introspección

Los clientes pueden consultar el esquema para descubrir las operaciones disponibles:

query {
  __schema {
    types {
      name
      fields {
        name
        type
      }
    }
  }
}

5. Un único endpoint

Todas las operaciones pasan por una única URL: /graphql

Debilidades de GraphQL

1. Complejidad

GraphQL es más difícil de aprender que REST. Consultas, mutaciones, suscripciones, resolvers: hay más que entender.

2. El almacenamiento en caché es más difícil

El almacenamiento en caché HTTP no funciona bien. Necesitas estrategias de almacenamiento en caché personalizadas.

3. Riesgo de sobre-consulta (over-querying)

Los clientes pueden escribir consultas costosas:

query {
  pets {
    orders {
      items {
        product {
          reviews {
            author {
              pets {
                # ¡Profundidad infinita!
              }
            }
          }
        }
      }
    }
  }
}

Necesitas límites de profundidad de consulta y análisis de complejidad.

4. Las cargas de archivos son incómodas

GraphQL no fue diseñado para cargas de archivos. Necesitas soluciones alternativas.

5. La monitorización es más difícil

Todas las solicitudes van a /graphql. No puedes monitorizar por URL.

Cuándo usar GraphQL

Aplicaciones móviles (reduce el ancho de banda)
Requisitos de datos complejos
Cuando los clientes necesitan flexibilidad
APIs internas con clientes conocidos
Cuando quieres evitar el versionado

Implementación GraphQL de Modern PetstoreAPI

gRPC: RPC de alto rendimiento

gRPC utiliza Protocol Buffers para una comunicación binaria eficiente.

Cómo funciona gRPC

Define servicios en archivos .proto:

service PetService {
  rpc GetPet(GetPetRequest) returns (Pet);
  rpc ListPets(ListPetsRequest) returns (ListPetsResponse);
  rpc CreatePet(CreatePetRequest) returns (Pet);
}

message Pet {
  string id = 1;
  string name = 2;
  string species = 3;
  PetStatus status = 4;
}

Código cliente (generado):

client := pb.NewPetServiceClient(conn)
pet, err := client.GetPet(ctx, &pb.GetPetRequest{
    Id: "019b4132-70aa-764f-b315-e2803d882a24",
})

Fortalezas de gRPC

1. Rendimiento

Los Protocol Buffers son más pequeños y rápidos que JSON:

Cargas útiles 3-10 veces más pequeñas
Serialización 20-100 veces más rápida

2. Streaming

Soporte integrado para streaming de servidor, streaming de cliente y streaming bidireccional:

rpc WatchPets(WatchPetsRequest) returns (stream Pet);

3. Tipado fuerte

Los Protocol Buffers imponen tipos en tiempo de compilación.

4. Generación de código

Genera código de cliente y servidor en más de 10 lenguajes a partir de archivos .proto.

5. HTTP/2

Multiplexación, compresión de encabezados y envío de servidor (server push).

Debilidades de gRPC

1. No es compatible con navegadores

Los navegadores no admiten el streaming bidireccional HTTP/2. Necesitas grpc-web (una solución alternativa).

2. No es legible por humanos

Los Protocol Buffers son binarios. No puedes hacer un curl a un endpoint gRPC y leer la respuesta.

3. Más difícil de depurar

Los protocolos binarios son más difíciles de inspeccionar que JSON.

4. Menos herramientas

Menos herramientas en comparación con REST. No hay un equivalente de Swagger UI.

5. Curva de aprendizaje más pronunciada

Protocol Buffers, generación de código y conceptos de gRPC requieren tiempo para aprenderse.

Cuándo usar gRPC

Comunicación de microservicios
Requisitos de alto rendimiento
Streaming en tiempo real
APIs internas (no públicas)
Entornos políglotas (múltiples lenguajes)

Implementación gRPC de Modern PetstoreAPI

Comparación lado a lado

Característica	REST	GraphQL	gRPC
Protocolo	HTTP/1.1 o HTTP/2	HTTP/1.1 o HTTP/2	Solo HTTP/2
Formato de Datos	JSON (usualmente)	JSON	Protocol Buffers (binario)
Endpoints	Múltiples (`/pets`, `/orders`)	Único (`/graphql`)	Métodos de servicio
Sobre-obtención	Común	Raro	N/A (tú defines los mensajes)
Sub-obtención	Común (N+1)	Raro	N/A
Almacenamiento en caché	Excelente (HTTP)	Pobre	Pobre
Soporte en Navegadores	Excelente	Excelente	Pobre (necesita grpc-web)
Herramientas	Excelente	Bueno	Regular
Curva de Aprendizaje	Fácil	Media	Difícil
Rendimiento	Bueno	Bueno	Excelente
Streaming	No (necesita WebSocket)	Sí (suscripciones)	Sí (nativo)
Versionado	URL o encabezado	Evolución de esquema	Evolución de Proto
Mejor Para	APIs públicas, CRUD	Clientes flexibles	Microservicios

Cómo Modern PetstoreAPI implementa los tres

Modern PetstoreAPI es única: implementa la misma API de tienda de mascotas en REST, GraphQL y gRPC.

Mismos datos, tres protocolos

Obtener una mascota por ID:

REST:

GET https://petstoreapi.com/v1/pets/019b4132-70aa-764f-b315-e2803d882a24

GraphQL:

query {
  pet(id: "019b4132-70aa-764f-b315-e2803d882a24") {
    id
    name
    species
  }
}

gRPC:

pet, err := client.GetPet(ctx, &pb.GetPetRequest{
    Id: "019b4132-70aa-764f-b315-e2803d882a24",
})

Los tres devuelven los mismos datos de la mascota.

¿Por qué implementar los tres?

1. Aprender por comparación

Observa cómo las mismas operaciones funcionan en diferentes protocolos.

2. Elige la herramienta adecuada

Usa REST para endpoints públicos, GraphQL para aplicaciones móviles, gRPC para servicios internos.

3. Ruta de migración

Comienza con REST, agrega GraphQL o gRPC más tarde sin reescribirlo todo.

4. Implementación de referencia

Modern PetstoreAPI muestra patrones listos para producción para los tres protocolos.

Consulta la guía de comparación de protocolos para ejemplos detallados.

Probando APIs multiprotocolo con Apidog

Apidog soporta REST, GraphQL y gRPC en una sola herramienta.

Probando REST

Importa la especificación OpenAPI y ejecuta pruebas automatizadas:

pm.test("Status is 200", () => {
    pm.response.to.have.status(200);
});

pm.test("Pet has required fields", () => {
    const pet = pm.response.json();
    pm.expect(pet).to.have.property('id');
    pm.expect(pet).to.have.property('name');
});

Probando GraphQL

Escribe consultas GraphQL y valida las respuestas:

query GetPet($id: ID!) {
  pet(id: $id) {
    id
    name
    species
  }
}

Apidog valida contra el esquema GraphQL.

Probando gRPC

Importa archivos .proto y prueba los servicios gRPC:

service: PetService
method: GetPet
request: { "id": "019b4132-70aa-764f-b315-e2803d882a24" }

Apidog genera solicitudes a partir de definiciones de Protocol Buffer.

Pruebas entre protocolos

Prueba que los tres protocolos devuelven datos consistentes:

Llamar al endpoint REST
Realizar consulta GraphQL
Llamar al método gRPC
Comparar respuestas

Apidog ayuda a asegurar que tu API multiprotocolo se mantenga consistente.

Eligiendo el protocolo adecuado

Usa este árbol de decisión:

¿Es una API pública?→ Sí: Usa REST (máxima compatibilidad) → No: Continuar

¿Necesitas streaming en tiempo real?→ Sí: Usa gRPC o WebSocket → No: Continuar

¿Los clientes necesitan una obtención de datos flexible?→ Sí: Usa GraphQL → No: Continuar

¿El rendimiento es crítico (microservicios)?→ Sí: Usa gRPC → No: Usa REST (opción más simple)

Ejemplos del mundo real

Stripe: REST (API pública, simple, cacheable)
GitHub: REST + GraphQL (REST para público, GraphQL para consultas complejas)
Google Cloud: gRPC + REST (gRPC para rendimiento, REST para compatibilidad)
Netflix: GraphQL (las aplicaciones móviles necesitan datos flexibles)
Uber: gRPC (comunicación de microservicios)

¿Puedes usar varios protocolos?

¡Sí! Modern PetstoreAPI muestra cómo. Patrones comunes:

REST para API pública
GraphQL para aplicaciones móviles
gRPC para microservicios internos

Cada protocolo sirve a diferentes clientes con diferentes necesidades.

Conclusión

REST, GraphQL y gRPC no son competidores, son herramientas para diferentes trabajos. REST es universal y simple. GraphQL da control a los clientes. gRPC es rápido y eficiente.

Modern PetstoreAPI implementa los tres, mostrando cómo la misma API funciona en diferentes protocolos. Puedes explorar la documentación REST, el esquema GraphQL y los archivos proto de gRPC para ver ejemplos listos para producción.

Usa Apidog para probar los tres protocolos, comparar implementaciones y asegurar la consistencia en tu API multiprotocolo.

El mejor protocolo es el que resuelve tu problema específico. Modern PetstoreAPI te brinda el conocimiento para elegir sabiamente.

botón

Preguntas frecuentes

¿Puedo usar REST y GraphQL juntos?

Sí. Muchas APIs ofrecen ambos. Usa REST para operaciones simples y GraphQL para consultas complejas. GitHub lo hace.

¿gRPC está reemplazando a REST?

No. gRPC es para microservicios internos. REST sigue siendo el estándar para APIs públicas debido a una mejor compatibilidad y herramientas.

¿Qué protocolo es el más rápido?

gRPC es el más rápido debido a Protocol Buffers y HTTP/2. Pero para la mayoría de las APIs, la diferencia no importa; la latencia de la red domina.

¿Debo migrar de REST a GraphQL?

Solo si tienes el problema de sobre-obtención/sub-obtención. No migres solo porque GraphQL esté de moda.

¿Los navegadores pueden usar gRPC?

No directamente. Necesitas grpc-web, lo que añade complejidad. Para clientes de navegador, usa REST o GraphQL.

¿Cómo mantiene Modern PetstoreAPI los tres protocolos sincronizados?

Capa de lógica de negocio compartida. REST, GraphQL y gRPC son adaptadores de protocolo delgados sobre la misma API central.

¿Qué protocolo deberían usar las startups?

Empieza con REST. Es simple, bien entendido y tiene excelentes herramientas. Agrega GraphQL o gRPC más tarde si los necesitas.

¿Apidog soporta los tres protocolos?

Sí. Apidog soporta REST (OpenAPI), GraphQL y gRPC en una sola herramienta, lo que facilita la prueba de APIs multiprotocolo como Modern PetstoreAPI.