Depuis plus de 10 ans, j'utilise et programme des API REST. C’est de loin l’un des systèmes les plus simples à intégrer lorsqu’il s’agit d’API. Il repose essentiellement sur des requêtes HTTP qui prennent la forme de méthodes bien connues telles que GET, POST, PUT, et DELETE. Difficile de faire plus efficace en termes de simplicité.
En termes de sécurité, l'autorisation dans REST se fait généralement via le header ou avec un système de jetons, comme OAuth, ce qui est une solution assez standardisée.
Puis, en 2015, Facebook a introduit GraphQL. Mais que veut dire "QL" ? C’est l’abréviation de Query Language, un langage de requête. GraphQL permet de demander uniquement les informations spécifiques dont on a besoin. C’est une approche que j’aime beaucoup, surtout parce que lorsqu’on développe une API, on ne sait pas toujours exactement comment le frontend va manipuler l’information.
Dans REST, une API utilise souvent Swagger pour la documentation et l'interaction. Swagger est une spécification qui décrit les endpoints disponibles dans une API, les types de requêtes possibles (GET, POST, etc.), et les paramètres attendus. Swagger fournit également une interface graphique qui permet de tester facilement les différentes routes de l'API, ce qui est un grand avantage pour les développeurs.
Les deux modèles permettent de spécifier des paramètres d’entrée. Cependant, dans Swagger, il est difficile de spécifier les paramètres de retour. REST, par défaut, renvoie souvent toutes les informations en une seule fois, même celles qui ne sont pas nécessaires. GraphQL ne rencontre pas ce problème, car le client peut spécifier exactement les champs qu’il souhaite dans la réponse.
En REST, il peut être nécessaire de faire plusieurs requêtes HTTP pour obtenir des informations de modèles différents. GraphQL, en revanche, permet de combiner plusieurs modèles en une seule requête. De plus, GraphQL excelle dans la gestion des relations complexes entre objets, là où REST montre ses limites.
Bien que GraphQL présente des avantages, sa complexité d'implémentation est un inconvénient. Il est nécessaire d’utiliser des librairies comme Graphene en Python et des sous-plugins comme graphene-django. L’upload de fichiers reste également une difficulté avec GraphQL, où il faut souvent encoder les fichiers en base64, ce qui alourdit les requêtes.
Dans les situations où il y a une séparation claire entre le développeur backend et frontend, je privilégie GraphQL. Il donne beaucoup d’indépendance au frontend, qui peut explorer les API de manière autonome. D’un autre côté, REST reste plus simple et peut être plus adapté à des projets où les besoins d’API sont plus basiques.
En fin de compte, REST reste une excellente solution pour des projets simples et faciles à maintenir. Cependant, GraphQL devient de plus en plus incontournable lorsque l’on travaille avec des systèmes complexes où de multiples requêtes et relations doivent être gérées efficacement. Pour mes projets récents, j’utilise principalement GraphQL, surtout quand la collaboration entre frontend et backend est cruciale.
Documentation officielle de Swagger
https://swagger.io/docs/
Graphene-Django
https://docs.graphene-python.org/projects/django/en/latest/
Vincent Cantin Bellemare
6 September 2024