GraphQL vs REST en Kotlin : que choisir pour le backend en 2025

Introduction : REST est mort, vive GraphQL ? (Spoiler : non)

Si vous codez en Kotlin et développez un backend, vous avez sûrement entendu parler de la guerre sainte : GraphQL vs REST. Dans un coin du ring, le bon vieux REST que tout junior connaît. Dans l'autre, le tendance GraphQL qui promet « donne-moi ce que je veux, mais en une seule requête ».

Je suis développeur backend avec de l'expérience en Kotlin, et ces dernières années, j'ai réécrit trois projets de REST vers GraphQL et inversement. Spoiler : chaque outil est bon pour sa tâche. Dans cet article, nous ne serons pas fanatiques. Au lieu de cela, nous analyserons avec des exemples de code réels quand REST en Kotlin gagne, et quand GraphQL est votre sauveur.

C'est parti pour une comparaison de GraphQL et REST en Kotlin sans blabla ni marketing.

1. L'essentiel en bref : qu'est-ce que c'est

Avant de plonger dans le code, mettons-nous d'accord sur les termes. REST API est un style architectural où chaque ressource (utilisateur, commande, produit) a sa propre URL et des méthodes HTTP (GET, POST, PUT, DELETE). Les développeurs Kotlin utilisent le plus souvent Spring Boot ou Ktor pour créer des services REST.

GraphQL est un langage de requêtes où vous avez un seul endpoint (généralement /graphql), et le client décide lui-même des champs dont il a besoin. En Kotlin, les bibliothèques populaires sont KGraphQL (légère) et Spring for GraphQL (pour les fans de Spring).

La différence clé : REST, c'est « le serveur dicte ce qu'il renvoie ». GraphQL, c'est « le client demande uniquement ce dont il a besoin ».

2. Exemple d'API REST en Kotlin (Ktor)

Commençons par le classique. Supposons que nous ayons une boutique en ligne. Il faut obtenir les données d'un utilisateur et ses dernières commandes.

Voici à quoi ressemble un contrôleur REST typique avec Ktor (framework léger pour 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 pour la réponse\n@Serializable\ndata class UserResponse(\n    val id: Int,\n    val name: String,\n    val email: String,\n    val lastOrders: List<Order>\n)

Problème : si le client (application mobile) a besoin uniquement de l'email de l'utilisateur, le serveur renverra quand même l'objet complet UserResponse avec les commandes. C'est du over-fetching — transfert de données excessif. Sur les réseaux mobiles faibles, c'est pénible.

Solution numéro un : créer plusieurs petits endpoints : GET /api/users/{id}/email. Mais alors le nombre de requêtes augmente (under-fetching).

3. Exemple GraphQL en Kotlin (Spring for GraphQL)

Maintenant, le même scénario, mais avec GraphQL. Voici le schéma (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}

Et voici le code Kotlin utilisant Spring for GraphQL (approche par annotations) :

@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 sans champs superflus\ndata class User(val id: Int, val name: String, val email: String, val lastOrders: List<Order>)

Maintenant, le client peut demander uniquement ce dont il a besoin :

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