GraphQL vs REST en Kotlin: qué elegir para el backend en 2025

Introducción: ¿REST ha muerto, larga vida a GraphQL? (Spoiler: no)

Si programas en Kotlin y desarrollas backend, seguramente has oído hablar de la guerra santa: GraphQL vs REST. En una esquina del ring está el viejo y querido REST, que todo junior conoce. En la otra, el moderno GraphQL, que promete «dame lo que sea, pero con una sola consulta».

Soy desarrollador backend con experiencia en Kotlin, y en los últimos años he reescrito tres proyectos de REST a GraphQL y viceversa. Spoiler: cada herramienta es buena para su tarea. En este artículo no seremos fanáticos. En su lugar, analizaremos con ejemplos de código reales cuándo gana REST en Kotlin y cuándo GraphQL es tu salvador.

Vamos a ver la comparación de GraphQL y REST en Kotlin sin rodeos ni marketing.

1. Brevemente sobre lo principal: qué es qué

Antes de meternos en el código, acordemos los términos. REST API es un estilo arquitectónico donde cada recurso (usuario, pedido, producto) tiene su propia URL y métodos HTTP (GET, POST, PUT, DELETE). Los desarrolladores de Kotlin suelen usar Spring Boot o Ktor para crear servicios REST.

GraphQL es un lenguaje de consultas donde tienes un único endpoint (generalmente /graphql), y el cliente decide qué campos necesita. En Kotlin son populares las bibliotecas KGraphQL (ligera) y Spring for GraphQL (para fanáticos de Spring).

La diferencia clave: REST es «el servidor dicta qué devolver». GraphQL es «el cliente pide solo lo que necesita».

2. Ejemplo de API REST en Kotlin (Ktor)

Empecemos con lo clásico. Supongamos que tenemos una tienda en línea. Necesitamos obtener datos de un usuario y sus últimos pedidos.

Así se ve un controlador REST típico en Ktor (framework ligero para Kotlin):

// REST endpoint: GET /api/users/{id}\nfun Application.userModule() {\n    routing {\n        get("/api/users/{id}") {\n            val userId = call.parameters["id"]?.toIntOrNull() ?: return@get call.respondText("Bad Request", status = HttpStatusCode.BadRequest)\n            val user = userService.getUserById(userId) ?: return@get call.respondText("Not Found", status = HttpStatusCode.NotFound)\n            call.respond(user)\n        }\n    }\n}\n\n// Data class para la respuesta\n@Serializable\ndata class UserResponse(\n    val id: Int,\n    val name: String,\n    val email: String,\n    val lastOrders: List<Order>\n)

Problema: si el cliente (aplicación móvil) solo necesita el email del usuario, el servidor igualmente devolverá el objeto completo UserResponse con los pedidos. Esto es over-fetching — transferencia excesiva de datos. En redes móviles lentas, esto duele.

La solución número uno es crear varios endpoints pequeños: GET /api/users/{id}/email. Pero entonces aumenta la cantidad de solicitudes (under-fetching).

3. Ejemplo de GraphQL en Kotlin (Spring for GraphQL)

Ahora el mismo escenario, pero con GraphQL. Aquí está el esquema (schema.graphqls):

type Query {\n    user(id: ID!): User\n}\n\ntype User {\n    id: ID!\n    name: String\n    email: String\n    lastOrders: [Order]\n}\n\ntype Order {\n    id: ID!\n    total: Float\n    date: String\n}

Y este es el código Kotlin usando Spring for GraphQL (enfoque de anotaciones):

@Controller\nclass UserController(private val userService: UserService) {\n\n    @QueryMapping\n    fun user(@Argument id: Int): User {\n        return userService.getUserById(id) ?: throw UserNotFoundException("User not found")\n    }\n}\n\n// Data class sin campos adicionales\ndata class User(val id: Int, val name: String, val email: String, val lastOrders: List<Order>)

Ahora el cliente puede solicitar solo lo que necesita:

query {\n    user(id: 42) {\n        email\n    }\n}