Qu’est-ce qu’une API REST ?
Les API REST (Representational State Transfer) sont des interfaces de programmation qui suivent les principes et les comportements du World Wide Web (WWW) pour faciliter la communication entre les clients et les serveurs dans les réseaux. Contrairement à d’autres interfaces comme SOAP ou WSDL, les API REST offrent une alternative basée sur une architecture standardisée, utilisant des protocoles tels que HTTP/S, les URI, JSON ou XML.
REST est l’acronyme de REpresentational State Transfer, et API signifie Application Programming Interface. Tous deux sont essentiels à la communication M2M.
L’approche architecturale appelée REST, ou ReST, a été développée par Roy Fielding en parallèle avec HTTP 1.1 et présentée dans sa thèse intitulée “Architectural Styles and the Design of Network-based Software Architectures” en 2000. Il n’est donc pas surprenant que le World Wide Web fournisse déjà une grande partie de l’infrastructure nécessaire à REST et que de nombreux services web soient conformes à cette architecture. Par exemple, de nombreux services en ligne fournissent du contenu statique via HTTP. Pour faciliter le traitement automatisé par les serveurs, les informations sont souvent fournies sous forme de JSON (JavaScript Object Notation) ou d’XML, représentant les données brutes initiales et n’étant pas nécessairement conformes à leur format d’origine.
Les six principes architecturaux de REST
REST ne spécifie pas en détail comment les services conformes doivent être implémentés. En revanche, l’approche repose sur six principes architecturaux (“contraintes”) :
Modèle client-serveur : REST exige un modèle client-serveur, séparant l’interface utilisateur de la gestion des données. Cela facilite la portabilité des clients sur différentes plates-formes, tandis que les composants serveur simplifiés améliorent la scalabilité.
Stateless : Les clients et les serveurs doivent communiquer de manière sans état (“stateless”). Cela signifie que chaque requête d’un client contient toutes les informations nécessaires au serveur et que le serveur ne peut pas utiliser de contexte stocké. Cette contrainte améliore la visibilité, la fiabilité et la scalabilité, mais entraîne des inconvénients en termes de performance réseau et fait perdre aux serveurs le contrôle d’un comportement cohérent de l’application cliente.
Mise en cache : Pour améliorer l’efficacité du réseau, les clients peuvent stocker les réponses envoyées par le serveur et les réutiliser lors de requêtes similaires ultérieures. Les informations doivent donc être marquées comme “cacheable” ou “non-cacheable”. Les avantages d’applications plus réactives, plus efficaces et plus scalables sont associés au risque que les clients se réfèrent à des données obsolètes dans le cache.
Interface uniforme : Les composants des services conformes à REST utilisent une interface uniforme, générale et indépendante du service implémenté. L’objectif est de simplifier l’architecture et d’accroître la visibilité des interactions. Cela implique une inefficacité accrue lorsque les informations sont formatées dans un format standard et ne sont pas adaptées aux besoins d’applications spécifiques.
Système en couches : REST repose sur des systèmes en couches hiérarchiques, où chaque composant ne peut voir que les couches adjacentes directes. Cela permet, par exemple, d’encapsuler des applications héritées. Les intermédiaires agissant en tant qu’équilibrage de charge peuvent également améliorer la scalabilité. Les inconvénients de cette contrainte sont un surcoût supplémentaire et une latence accrue.
Code-On-Demand : Cette contrainte exige que les fonctionnalités des clients puissent être étendues via des parties de programme téléchargeables et exécutables, telles que des applets ou des scripts. Bien que ce soit une contrainte facultative qui peut être désactivée dans certains contextes.
Implémentation via HTTP
Le paradigme REST est généralement mis en œuvre via HTTP/S. Les services sont adressés via des URL/URI. Les méthodes HTTP (GET, POST, PUT, DELETE, etc.) indiquent l’opération que le service doit effectuer.
Utilisation pratique de GET, POST, PATCH et DELETE en REST
Étant donné que le World Wide Web fournit déjà une grande partie de l’infrastructure nécessaire à REST, il est possible de commencer à expérimenter les interfaces REST dès maintenant en utilisant simplement un navigateur. Une introduction possible à cette pratique est proposée, par exemple, par la “Fake Online REST API for Testing and Prototyping” disponible à l’adresse jsonplaceholder.typicode.com.
Cette solution permet d’accéder à une série d’enregistrements de données liés les uns aux autres. La ressource souhaitée et les éventuels paramètres sont ajoutés à l’URL après le slash. Les ressources proposées comprennent 100 articles, 500 commentaires, 100 albums, 5000 photos, 200 listes de tâches et 10 utilisateurs. Les méthodes HTTP prises en charge sont les suivantes :
- GET : demande des données au serveur
- POST : transmet des données au serveur
- PUT/PATCH : modifie des données existantes sur le serveur
- DELETE : supprime des données existantes sur le serveur
Cependant, les utilisateurs ne sont pas autorisés à modifier ou à supprimer des données via cette API REST créée à des fins de démonstration. Le serveur rejette donc toutes les demandes de ce type. Vous pouvez donc essayer librement sans craindre de causer des dommages.
Il n’y a donc aucune raison de ne pas lancer votre navigateur préféré et de demander des données à un serveur en utilisant la méthode GET, ce qui se produit en réalité lorsque vous entrez une URL dans la barre d’adresse et recevez une page web en retour. Si vous demandez des données à l’adresse jsonplaceholder.typicode.com/posts, l’offre vous donnera déjà une liste assez complète de faux articles. Avec le navigateur Firefox, vous pouvez également afficher les données JSON peu attrayantes de manière claire et lisible : pliable et formaté en couleur.
Postman, un environnement de développement d’API couramment utilisé.
Postman : Développement d’API avec simplicité
Pour aller plus loin, l’environnement de développement d’API (APE) Postman offre encore plus de possibilités. Cet outil est disponible sur différentes plateformes (Windows, macOS, Linux et ChromeOS) et peut être utilisé gratuitement dans sa version de base.
Comme pour un navigateur, Postman dispose également d’une barre d’adresse où vous pouvez demander des données via une URL. Contrairement aux navigateurs mentionnés précédemment, le logiciel est entièrement axé sur le développement et offre donc des possibilités de manipulation des données beaucoup plus étendues. Mais une étape à la fois.
Il est donc judicieux, tout comme avec un navigateur, de commencer par saisir la requête précédemment envoyée sous forme de navigation web. La méthode GET affichée à gauche est activée par défaut, un clic sur Send fournit la liste demandée dans la partie inférieure de l’écran. Sur demande, Postman formate la liste – en plus du texte brut, le programme prend également en charge les formats JSON, XML et HTML. De plus, les utilisateurs peuvent obtenir des détails sur l’état du serveur, la durée de la requête et la taille du document reçu. L’outil affiche également les cookies et les en-têtes transmis.
En cliquant sur le bouton Params à droite de la barre d’adresse, vous pouvez affiner votre requête. Par exemple, si vous utilisez le “UserId” comme clé et la valeur “3” comme valeur, la requête suivante ne renverra que les publications de l’utilisateur “3”. Vous pouvez également découvrir qui se cache derrière ce numéro anonyme : la requête adaptée avec le paramètre correspondant, également utilisable par les navigateurs web, est jsonplaceholder.typicode.com/users?id=3 et renvoie l’enregistrement de données d’une certaine “Clementine Bauch” avec le nom d’utilisateur inapproprié “Samantha”. Si vous souhaitez le modifier, la méthode PATCH est préférable. En cliquant sur GET, vous pouvez modifier la méthode dans Postman, et les paramètres ajustés fournissent la demande PATCH suivante : http://jsonplaceholder.typicode.com/users?id=3&username=Clementine – mais cette API fictive renvoie un statut 404 ; cela se produit également lorsque vous essayez de supprimer l’enregistrement de données.
Les API REST peuvent bien sûr également être utilisées directement via du code. Nous avons utilisé PHP comme exemple pour établir une connexion avec le serveur en utilisant la bibliothèque cURL et rechercher les articles de l’utilisateur numéro 3 – aka Clementine. Les données renvoyées sont converties en un tableau correspondant à l’aide de “json_decode” et finalement affichées. Le résultat est visible dans la galerie d’images.
JSON (JavaScript Object Notation) – pour l’échange de données structurées.
Conclusion
Les API REST offrent un moyen efficace de communiquer entre les clients et les serveurs en utilisant l’architecture du World Wide Web. En utilisant des principes architecturaux solides tels que le modèle client-serveur, la mise en cache et une interface uniforme, les API REST peuvent simplifier le développement et améliorer la scalabilité des systèmes distribués. Que vous souhaitiez simplement expérimenter avec votre navigateur ou développer des applications plus avancées avec des outils spécifiques tels que Postman, les API REST offrent un potentiel considérable pour faciliter la communication entre les composants logiciels dans le monde moderne d’aujourd’hui.
