TL;version DR

Dans l'un des articles précédents, nous avons discuté, en bref, de l'utilisation de l'API GitHub v3. Cette version est conçue pour être interfacée comme n'importe quelle autre API REST. Il existe des points de terminaison pour chaque ressource que vous devez accéder et/ou modifier. Il existe des points de terminaison pour chaque utilisateur, chaque organisation, chaque référentiel, etc. Par exemple, chaque utilisateur a son point de terminaison API sur https://api.github.fr/utilisateurs/ vous pouvez essayer de remplacer votre nom d'utilisateur au lieu de et entrez l'URL dans un navigateur pour voir avec quoi l'API répond.

L'API GitHub v4, quant à elle, utilise GraphQL où le QL signifie Query Language. GraphQL est une nouvelle façon de concevoir vos API. Tout comme il existe de nombreux services Web proposés en tant qu'API REST, pas seulement ceux proposés par GitHub, il existe de nombreux services Web qui vous permettent de vous connecter avec eux via GraphQL.

La différence la plus frappante que vous remarquerez entre GraphQL et l'API REST est que GraphQL peut fonctionner à partir d'un seul point de terminaison d'API. Dans le cas de l'API GitHub v4, ce point de terminaison est https://api.github.com/graphql et c'est tout. Vous n'avez pas à vous soucier d'ajouter de longues chaînes à la fin d'un URI racine ou de fournir un paramètre de chaîne de requête pour des informations supplémentaires. Vous envoyez simplement un argument de type JSON à cette API, en ne demandant que les éléments dont vous avez besoin, et vous obtiendrez une charge utile JSON avec exactement les mêmes informations que vous avez demandées. Vous n'avez pas à filtrer les informations indésirables ou à subir une surcharge de performances en raison de réponses volumineuses.

Qu'est-ce que l'API REST?

Eh bien, REST signifie Representational State Transfer et API signifie Application Programming Interface. Une API REST, ou une API "RESTful", est devenue la philosophie de conception de base derrière la plupart des applications client-serveur modernes. L'idée émerge de la nécessité de séparer les divers composants d'une application comme l'interface utilisateur côté client et la logique côté serveur.

Ainsi, la session entre un client et un serveur est généralement sans état. Une fois la page Web et les scripts associés chargés, vous pouvez continuer à interagir avec eux et lorsque vous effectuez une action (comme appuyer sur un bouton d'envoi), une demande d'envoi est envoyée avec toutes les informations contextuelles dont le serveur Web a besoin pour traiter cette demande ( comme le nom d'utilisateur, les jetons, etc.). L'application passe d'un état à un autre mais sans besoin constant de connexion entre le client et le serveur.

REST définit un ensemble de contraintes entre le client et le serveur, et la communication ne peut se faire que sous ces contraintes. Par exemple, REST sur HTTP utilise généralement le modèle CRUD, qui signifie Create, Read, Update and Delete et les méthodes HTTP telles que POST, GET, PUT et DELETE vous aident à effectuer ces opérations et ces opérations seules. Les anciennes techniques d'intrusion telles que les injections SQL ne sont pas possibles avec quelque chose comme une API REST étroitement écrite (bien que REST ne soit pas une panacée de sécurité).

Cela aide également beaucoup les développeurs d'interface utilisateur! Étant donné que tout ce que vous recevez d'une requête HTTP est généralement un flux de texte (formaté en JSON, parfois), vous pouvez facilement implémenter une page Web pour les navigateurs ou une application (dans votre langue préférée) sans vous soucier de l'architecture côté serveur. Vous lisez la documentation de l'API pour des services comme Reddit, Twitter ou Facebook et vous pouvez écrire des extensions pour eux ou pour des clients tiers dans la langue de votre choix car vous avez la garantie que le comportement de l'API sera toujours le même.

Inversement, le serveur ne se soucie pas de savoir si le front-end est écrit en Go, Ruby ou Python. Qu'il s'agisse d'un navigateur, d'une application ou d'une CLI. Il « voit » simplement la demande et répond de manière appropriée.

Qu'est-ce que GraphQL?

Comme pour tout dans le monde des ordinateurs, les API REST sont devenues plus grandes et plus complexes et en même temps, les gens voulaient les implémenter et les utiliser de manière plus rapide et plus simple. C'est pourquoi Facebook a eu l'idée de GraphQL, et plus tard l'a ouvert. Le QL dans GraphQL signifie Query Language.

GraphQL permet aux clients de faire des demandes d'API très spécifiques, au lieu de faire des appels d'API rigides avec des paramètres et des réponses prédéfinis. C'est beaucoup plus simple car le serveur répond alors avec exactement les données que vous lui avez demandées, sans excès.

Jetez un œil à cette requête REST et à sa réponse correspondante. Cette demande est destinée à afficher uniquement la biographie publique d'un utilisateur.