GraphQL vs REST : quel est le meilleur choix pour la conception d’API ?

GraphQL permet aux clients d’interroger des données spécifiques et certaines. REST exploite la mise en cache HTTP et s’intègre facilement à d’autres API. Pour en savoir plus sur ces approches, consultez l’API publique de GitHub.

Dans le paysage technologique actuel en évolution rapide, la sélection de la bonne interface de programmation d’application (API) peut être essentielle au succès de votre application. La façon dont une application communique avec les autres peut grandement affecter ses performances, sa flexibilité et sa maintenabilité.

Deux approches populaires pour la conception d’API et souvent comparées les unes aux autres sont REPOS (Transfert d’État représentatif) et GraphQL. Les deux ont leurs avantages et leurs inconvénients, et le choix entre les deux dépend souvent des besoins spécifiques d’une application. Dans l’article d’aujourd’hui, nous comparerons ces deux technologies, en utilisant l’API publique GitHub comme exemple.

GitHub a deux versions de son API actives et rendues publiques : une API REST et une API GraphQL. Nous pouvons accéder à l’API REST de GitHub en faisant des requêtes à l’URL publique https://api.github.comalors que pour explorer l’API GraphQL de GitHub, nous pouvons aller sur https://docs.github.com/en/graphql/overview/explorer. Pour que cette interface GraphQL fonctionne, nous devrons être connectés avec un compte GitHub.

Récupération de la description d’un référentiel

Commençons par un exercice dans lequel nous visons à récupérer la description d’un référentiel particulier à l’aide des API REST et GraphQL. Le référentiel que nous utiliserons est celui de GitHub Bonjour le monde référentiel, créé par le profil Octocat. La description que nous aimerions récupérer pour le référentiel Hello-World est My first repository on GitHub!qui peut être vu dans l’interface utilisateur lorsque nous naviguons vers l’itinéraire du référentiel dans notre navigateur.

API REST

Quand nous visitons https://github.com/octocat/Hello-World dans notre navigateur, les informations du référentiel Hello-World nous sont présentées dans notre interface utilisateur. GitHub nous permet de voir les données renvoyées pour cette route en appuyant sur le bouton https://api.github.com/repos/octocat/Hello-World itinéraire. Nous faisons également une requête GET ici et les données renvoyées se présentent comme suit :

Bien que nous ayons réussi à récupérer le description champ que nous recherchons dans le référentiel, le serveur nous a envoyé beaucoup plus de données « inutiles » (c’est-à-dire inutiles pour notre intérêt actuel) telles que le name du référentiel, les détails du owner du référentiel et d’autres URL qui peuvent nous permettre de faire d’autres demandes pour obtenir plus d’informations. Quoi qu’il en soit, nous devons récupérer toutes ces informations malgré le fait que nous ne voulons que la valeur d’un seul champ.

API GraphQL

Comparons cela avec GraphQL. Nous passerons à l’explorateur GraphQL que GitHub fournit pour sa nouvelle API à l’adresse https://docs.github.com/en/graphql/overview/explorer. La première chose que l’on peut noter ici est que nous sommes capables d’interagir avec un environnement interactif pour faciliter les requêtes GraphQL. La possibilité d’utiliser des IDE est une fonctionnalité intéressante fournie par de nombreux services GraphQL différents.

L’explorateur GraphQL de GitHub traite les données de production en direct !
Vous pourrez très probablement supprimer des problèmes, des projets et peut-être même votre compte. Nous vous suggérons d’être prudent lorsque vous utilisez cet explorateur !

Nous souhaitons essentiellement faire une sorte de requête GET pour récupérer la description du référentiel Hello-World. Dans GraphQL, nous sommes capables de faire requêtes pour récupérer les données que nous voulons.

Nous allons spécifier la requête GraphQL qui nous aidera à renvoyer la description du référentiel Hello-World. Dans l’API GitHub GraphQL, le description domaine qui nous intéresse vit au sein d’un parent repository champ qui prend un argument du référentiel à interroger.

En conséquence, nous préciserons repository comme champ parent que nous voulons interroger et nous transmettrons les arguments conformes au référentiel Hello-World –owner: "octocat" et name: "Hello-World!". Nous déclarerons seulement un description champ à l’intérieur pour être le champ pour lequel nous souhaitons que les données soient renvoyées.

query {
  repository(owner: "octocat", name: "Hello-World") {
    description
  }
}

Lorsque nous exécutons la requête, nous obtenons la description attendue que nous recherchons.

Remarquez à quel point cette réponse est propre par rapport à la réponse renvoyée par notre API REST ? Nous obtenons seulement ce que nous demandons.

Récupération de plus d’informations sur le référentiel

Pour le prochain exercice, faisons quelque chose d’un peu plus compliqué. Imaginons que nous développions une application client qui doit afficher les informations suivantes à partir du même référentiel Hello-World :

• La description du référentiel.
• Le titre d’un certain numéro particulier dans le référentiel. Nous utiliserons numéro 348 du référentiel Hello-World.
• Les cinq premiers commentaires dudit numéro. Pour chaque commentaire, nous aimerions également afficher le nom d’utilisateur de l’auteur du commentaire et le corps du commentaire.

API REST

Pour y parvenir avec l’API REST, nous devrons effectuer trois requêtes différentes.

1. Une demande à https://api.github.com/repos/octocat/Hello-World pour obtenir la description du référentiel.
2. Une demande à https://api.github.com/repos/octocat/Hello-World/issues/348 pour récupérer le titre de numéro 348 du dépôt Hello-World.
3. Enfin, une autre demande à https://api.github.com/repos/octocat/Hello-World/issues/348/comments pour avoir les cinq (et bien d’autres !) commentaires de numéro 348.

Nous devrons faire trois demandes distinctes pour obtenir toutes les informations que nous pourrions rechercher.

API GraphQL

Avec une API GraphQL bien conçue, cela peut être facilité du point de vue du client. Voyons comment cela peut fonctionner pour le cas d’utilisation ci-dessus et l’API GraphQL de GitHub.

• Le dépôt le champ de requête contient un champ de problème cela nous permet d’interroger des informations sur un certain problème dans le référentiel.
• Pour obtenir des informations sur un problème donné, nous devons spécifier un number argument où nous pouvons fournir le numéro de problème.
• Le issue le champ contient un enfant champ de commentaire où les commentaires sur un problème peuvent être interrogés.
• comments dans issue est un champ paginé, nous pouvons donc interroger les cinq premiers en spécifiant un first argument avec une valeur de 5.
• Pagination dans comments suit un modèle basé sur un relaisqui contient les données que nous recherchons edges et puis nodes. Pour chaque commentaire que nous souhaitons interroger, nous souhaitons recevoir le bodyText du commentaire et le nom d’utilisateur du commentateur qui vit sous le author.logIn champ.

Cela dit, la requête que nous aimerions faire ressemble à ce qui suit :

query {
  repository(owner: "octocat", name: "Hello-World") {
    description
    issue(number: 348) {
      title
      comments(first: 5) {
        edges {
          node {
            bodyText
            author {
              login
            }
          }
        }
      }
    }
  }
}

Lorsque nous exécutons la requête, nous obtenons exactement ce que nous avions demandé !

GraphQL contre REST

Dans cet article, nous avons constaté un avantage significatif à utiliser GraphQL par rapport à REST, où GraphQL permet aux clients demander exactement ce dont ils ont besoin et rien de plus. Au-delà de la récupération de données spécifiques, GraphQL présente d’autres avantages, comme un schéma typé, des données en temps réel avec les abonnements GraphQL, et bien plus encore.

Malgré ces avantages, GraphQL n’est pas toujours le meilleur choix. Il existe des scénarios dans lesquels REST pourrait être plus approprié :

• Construire une API simple : Pour les API très simples avec un petit nombre de ressources et de relations, REST peut être plus simple et plus rapide à mettre en œuvre.
• Mise en cache HTTP : Les API REST peuvent exploiter la mise en cache HTTP pour améliorer les performances, qui est intégrée au protocole HTTP et largement prise en charge par les navigateurs et les CDN. Bien qu’il existe des moyens d’implémenter la mise en cache dans GraphQL, ce n’est pas aussi simple que dans REST.
• Intégration avec des services tiers : De nombreux services et outils tiers sont construits autour des API REST. Si vous devez intégrer de nombreux services externes, REST pourrait être une meilleure solution.

REST et GraphQL ont tous deux leurs forces et leurs faiblesses, et le choix entre les deux dépend souvent des besoins spécifiques d’une application. Dans cet article, nous avons comparé ces deux technologies en utilisant l’API publique GitHub comme exemple et nous nous sommes concentrés sur la manière dont GraphQL permet d’interroger des données spécifiques. Dans les prochains articles, nous approfondirons GraphQL et comment il se compare également à REST.