02 • 34 • 09 • 31 • 70
Qu'est-ce qu'une API ?
Le SOA (Service Oriented Architecture) est un paradigme utilisé pour faire communiquer plusieurs services entre eux. C’est dans ce contexte que s’inscrivent les API (Application Programming Interface) ou Interface de Programmation Applicative qui sont des systèmes qui renvoient des données de manière contrôlée à des consommateurs extérieurs. Une API permet généralement de faire le lien entre une base de données et une application.
Dans une application classique basée sur une architecture en trois éléments, elle se situe au milieu.
On retrouve donc plusieurs modèles d’API pour procéder à des échanges de données, et bien qu’il en existe d’autres, les trois principaux aujourd’hui sont les suivants : Soap, Rest et GraphQL.
API SOAP
SOAP (Simple Object Access Protocol) est un protocole standardisé par le W3C. Ses échanges utilisent des formats de fichier XML. Ce dernier est ancien, ce qui lui donne comme principal avantage d’être lisible par tous les langages.
Celui-ci peut également passer par divers modes de communications : HTTP, HTTPS, TCP, SMTP, POP, etc. Ce format d’API est très structuré, car toutes les méthodes et propriétés sont décrites par un document XML, le Web Services Description Language (WSDL).
Le SOAP permet de répondre à :
- des besoins asynchrones
- une validation forte des modèles d’échanges
- des opérations statefull
Ainsi le SOAP peut fonctionner dans des environnements distribués, possède sa gestion d’erreurs, est non dépendant du support et extensible, mais en contrepartie est très verbeux, plus compliqué à travailler et plus compliqué à comprendre que le REST.
Le SOAP est donc utilisé pour des besoins de sécurités des échanges forts, par exemple pour des systèmes financiers ou bancaires.
API REST
Les architectures REST (Representational State Transfer) reposent sur un échange client/serveur où les données sont structurées d’une manière à ne pas avoir la main dessus, c’est-à-dire que c’est le serveur qui gère cela en renvoyant du texte, du CSV, ou du JSON, par exemple.
L’une des caractéristiques fortes qui qualifie une API de REST est le HATEOAS (Hypermedia as the Engine of Application State). Cela se traduit par le fait que le client n’a pas besoin de connaissance au préalable (ou peu) pour interagir avec l’API. Cela passe par une structure forte des routes et des verbes utilisés.
Un verbe est un élément qui définit la manière d'interagir avec une ressource, les principales étant : “GET” pour lire une ressource, “POST” pour en créer une, “PUT” pour en modifier une, “PATCH” pour en modifier partiellement une, “DELETE” pour en supprimer une. Pour accéder à une ressource, en plus du verbe, un chemin est nécessaire indiquant le type de ressource :
“/nextie” pour une nextie, “/nextie/1” pour la nextie 1, “nextie/1/equipement” pour l’équipement d’une Nextie*
* Nextie est la mascotte licorne de Next Decision
Ainsi, voici un exemple d’intégration :
Le REST est donc utile pour un CRUD stateless, des besoins de caches et de support de plusieurs formats.
API GRAPHQL
GraphQL (Graph Query Language) est un nouveau type d’API bien plus récent. L’idée est de partir d’une API REST avec des formats de retour JSON, mais avec la subtilité en plus que le client doit envoyer les données qu’ils souhaite récupérer au serveur, cela via un Graph, un modèle de données. Ainsi, le serveur se retrouve à avoir une couche plus lourde d’initialisation des modèles, mais dans la finalité le tout est plus léger de par le moins grand nombre de déclarations de routes et de leurs fonctionnements propres.
Graph semble donc être l’avenir des API stateless de par ses qualités, mais son utilisation encore limitée peut le rendre un peu moins attrayant et donc plus complexe à prendre en main.
La meilleure API ?
Parmi toutes les API qui existent, laquelle est la meilleure ? Et bien, cela dépend :
- du besoin
- du contexte du projet (moyen physique et financier)
- des technologies utilisées, etc.
Une API SOAP peut être idéale dans des cas de systèmes complexes et très sécurisés comme pour le domaine financier. Dans des contextes plus simples, cela sera probablement plus une épine dans le pied qu’une solution.
Le REST est généralement l’idéal dans les projets les plus standards : des échanges simples et précis, qui permettent une interaction avec les données suffisantes. Celui-ci peut tout de même avoir ses limites si des problématiques de poids d'échanges des données sont de mise.
GraphQL a tout pour plaire et semble véritablement être l’avenir. Cependant la contrainte principale de celui-ci semble être surtout sa jeunesse et la capacité d’un développeur à rentrer dans ce mode de fonctionnement.
Il sera alors de notre rôle à nous, consultants Next Decision, de vous aiguiller afin d’adopter ensemble la meilleure solution pour votre projet.
Notre équipe d'experts est à l'écoute de vos besoins et projets d'API ! Rendez vous sur la page Contact