GraphQL vs REST en C# : que choisir pour votre API en 2024

GraphQL vs REST en C# : Bataille de titans ou choix de l'outil adapté à la tâche ?

Bonjour, collègues ! Si vous codez en C# et créez des API, la question "REST ou GraphQL ?" a sûrement déjà surgi. C'est comme débattre de ce qui est mieux : un marteau ou une visseuse. Ce sont tous deux des outils, mais pour des tâches différentes. Dans cet article, nous ne défendrons pas fanatiquement une technologie, mais analyserons sobrement, avec des exemples de code en C#, quand GraphQL l'emporte et quand le bon vieux REST reste roi.

Nous sommes l'équipe PythonLib, et bien que le nom contienne "Python", nous adorons l'écosystème .NET et C#. Aujourd'hui, plongeons dans le monde des API en C# et voyons comment ne pas se tromper dans le choix. C'est parti !

Petit rappel : REST et GraphQL pour le développeur C#

REST (Representational State Transfer) est un style architectural que nous connaissons et aimons tous. En C#, vous utilisez probablement ASP.NET Core Web API. Vous créez des contrôleurs, des points de terminaison, et chaque point de terminaison renvoie une structure de données fixe. Vous voulez obtenir un utilisateur ? Allez sur /api/users/1. Vous voulez ses commandes ? Allez sur /api/users/1/orders. Simple, prévisible, mais cela conduit souvent à du sur-chargement (recevoir des données inutiles) ou du sous-chargement (devoir faire plusieurs requêtes).

GraphQL est un langage de requêtes développé par Facebook. Dans le monde C#, il est implémenté via les bibliothèques Hot Chocolate (la plus populaire) ou GraphQL.NET. Vous avez un seul point de terminaison (généralement /graphql), et le client décide lui-même des champs dont il a besoin. Vous voulez le nom de l'utilisateur et seulement la première commande ? Pas de problème ! Pas de sur-chargement.

Comparaison pratique : code C#

Passons de la théorie au code. Imaginons que nous ayons un modèle simple : User et Order.

// Modèles de données\npublic class User\n{\n    public int Id { get; set; }\n    public string Name { get; set; }\n    public string Email { get; set; }\n    public string Phone { get; set; }\n    public List<Order> Orders { get; set; }\n}\n\npublic class Order\n{\n    public int Id { get; set; }\n    public string ProductName { get; set; }\n    public decimal Price { get; set; }\n    public DateTime CreatedAt { get; set; }\n}\n

Exemple d'API REST sur ASP.NET Core

[ApiController]\n[Route("api/[controller]")]\npublic class UsersController : ControllerBase\n{\n    [HttpGet("{id}")]\n    public async Task<ActionResult<User>> GetUser(int id)\n    {\n        // Supposons que les données viennent de la base de données\n        var user = await _dbContext.Users.FindAsync(id);\n        if (user == null) return NotFound();\n        return Ok(user); // Renvoie TOUS les champs : Id, Name, Email, Phone, Orders\n    }\n}\n

Le problème ? Si le client a besoin uniquement du nom et de l'email, il reçoit quand même Phone et Orders. Et s'il a besoin des commandes, il doit faire une requête séparée vers /api/users/1/orders.

Exemple d'API GraphQL sur Hot Chocolate

public class Query\n{\n    public async Task<User> GetUser(int id, [Service] AppDbContext dbContext)\n    {\n        return await dbContext.Users.FindAsync(id);\n    }\n}\n\n// Enregistrement dans Program.cs\nbuilder.Services\n    .AddGraphQLServer()\n    .AddQueryType<Query>();\n

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

// Requête GraphQL\n{\n  user(id: 1) {\n    name\n    email\n    orders {\n      productName\n      price\n    }\n  }\n}\n

La réponse contiendra uniquement name, email et un tableau orders avec les champs productName et price. Pas de données superflues. Magnifique !

Quand REST en C# gagne (et c'est normal)

1. Simplicité et mise en cache. Les API REST sont faciles à mettre en cache au niveau HTTP (CDN, proxy). Une requête GET sur /api/products peut être mise en cache, et tout b