GraphQL vs REST en Java : que choisir pour le backend en 2025 ?

GraphQL vs REST en Java : duel de titans sur votre backend

Imaginez que vous commandez une pizza. REST, c'est quand on vous apporte une pizza entière, même si vous ne vouliez qu'une seule part au pepperoni. GraphQL, c'est quand vous dites : « Donnez-moi, s'il vous plaît, seulement le pepperoni et le fromage, gardez la pâte et la sauce tomate ». Ça semble pratique ? C'est ce principe qui est à l'origine du principal débat dans le monde du développement Java ces dernières années.

REST et GraphQL sont deux approches puissantes pour construire des API, et chaque développeur Java se retrouve tôt ou tard face à un choix. GraphQL vs REST dans les projets Java n'est pas qu'une simple polémique, c'est un problème pratique dont dépendent la performance, la vitesse de développement et la facilité de maintenance. Analysons cela avec des exemples concrets et du code vivant.

REST : un vieil ami qui vaut mieux que deux nouveaux ?

REST (Representational State Transfer) est un style architectural qui domine le monde Java depuis plus de dix ans. Les services RESTful Java reposent sur des principes simples : ressources, méthodes HTTP (GET, POST, PUT, DELETE) et codes de statut. Tout est familier, prévisible et stable.

Exemple de contrôleur REST avec Spring Boot

@RestController\n@RequestMapping("/api/users")\npublic class UserController {\n\n    @Autowired\n    private UserService userService;\n\n    @GetMapping("/{id}")\n    public ResponseEntity<UserDTO> getUser(@PathVariable Long id) {\n        UserDTO user = userService.findById(id);\n        return ResponseEntity.ok(user);\n    }\n\n    @GetMapping\n    public ResponseEntity<List<UserDTO>> getAllUsers() {\n        List<UserDTO> users = userService.findAll();\n        return ResponseEntity.ok(users);\n    }\n}

Tout est propre, élégant, conforme aux canons. L'API REST Java fonctionne comme une horloge si vos clients sont des navigateurs et des applications mobiles qui savent quelles données ils ont besoin. Mais il y a un hic : REST souffre souvent de sur-récupération (over-fetching) et de sous-récupération (under-fetching) des données.

Supposons qu'une application mobile n'ait besoin que du nom d'utilisateur et de son email. Une requête REST GET /api/users/1 renverra l'objet UserDTO complet avec tous les champs, y compris l'adresse, le téléphone, l'historique des commandes. Du trafic inutile, une charge supplémentaire. Ça vous dit quelque chose ?

GraphQL : un nouveau venu ambitieux

GraphQL est un langage de requête développé par Facebook (aujourd'hui Meta) en 2012. GraphQL Java est l'implémentation de la spécification pour l'écosystème Java. Contrairement à REST, GraphQL a un seul point d'entrée (généralement /graphql), et le client décide lui-même des champs dont il a besoin.

Exemple de schéma GraphQL en Java avec graphql-java et Spring Boot

// Définition du schéma (dans le fichier schema.graphqls)\ntype Query {\n    user(id: ID!): User\n    users: [User]\n}\n\ntype User {\n    id: ID!\n    name: String!\n    email: String!\n    address: String\n    phone: String\n}\n\n// Contrôleur GraphQL (Spring Boot + graphql-java-spring-boot-starter)\n@Component\npublic class UserGraphQLQuery implements GraphQLQueryResolver {\n\n    @Autowired\n    private UserService userService;\n\n    public User user(Long id) {\n        return userService.findById(id);\n    }\n\n    public List<User> users() {\n        return userService.findAll();\n    }\n}

Le client peut maintenant envoyer une requête comme celle-ci :

{\n  user(id: 1) {\n    name\n    email\n  }\n}

Et il obtiendra exactement ce qu'il a demandé : { "data": { "user": { "name": "Ivan", "email": "ivan@example.com" } } }. Pas de données superflues. La comparaison entre GraphQL et REST dans cet aspect est clairement en faveur du premier.

Quand REST gagne : cas d'usage pour les projets Java

Malgré toute la magie de GraphQL, REST reste le roi dans certains scénarios. Les services RESTful Java sont idéaux lorsque :

\n
• Simplicité et transparence
\n