Bonjour, aujourd'hui, nous étudierons un sujet très intéressant et surtout demandé sur le marché du travail - REST. Nous diviserons la présentation de REST en trois parties :
Dans la première partie, nous aborderons l’histoire de REST et décrirons les principes sur lesquels repose REST.
Dans la seconde, nous verrons comment s'effectue la communication entre le client et le serveur via le protocole HTTP.
Dans la troisième, nous écrirons une petite application RESTful, que nous testerons à l'aide du programme Postman.
L'article s'adresse à un lecteur familiarisé avec les termes suivants :
HTTP ;
URL et URI ;
JSON et dans une moindre mesure XML ;
Injection de dépendances.
Partie 1. Qu'est-ce que REST
REST, comme beaucoup de choses dans le monde informatique, est un acronyme pour Representational State Transfer . Il s'agit d'un style architectural d'interaction entre les composants d'un système distribué dans un réseau informatique. En termes simples, REST définit un style d'interaction (échange de données) entre différents composants d'un système, chacun pouvant être physiquement situé à des endroits différents. Ce style architectural représente un ensemble cohérent de contraintes prises en compte lors de la conception d'un système distribué. Ces restrictions sont parfois appelées principes REST. Il n'y en a pas beaucoup, seulement 6 pièces. Nous en parlerons un peu plus tard.
Applications construites avec REST à l'esprit, c'est-à-dire qui ne violent pas les restrictions imposées par REST sont appelés RESTful.
Histoire de REST
Le terme REST a été inventé par Roy Fielding, l'un des créateurs du protocole HTTP, dans sa thèse de doctorat « Styles architecturaux et conception d'architectures logicielles basées sur réseau » en 2000. On peut dire que le terme REST est encore jeune, même si son concept est à la base même du World Wide Web. Nous n’approfondirons pas l’histoire de l’origine de ce terme. Si vous souhaitez plonger dans les sources originales, jetez un œil à la thèse de Fielding .
Restrictions et principes REST
Comme indiqué ci-dessus, REST définit la manière dont les composants d'un système distribué doivent interagir les uns avec les autres. En général, cela se produit via une requête-réponse. Le composant qui envoie la requête est appelé le client ; Le composant qui traite la demande et envoie une réponse au client est appelé serveur . Les requêtes et les réponses sont le plus souvent envoyées via HTTP (HyperText Transfer Protocol). En règle générale, un serveur est une sorte d’application Web. Le client ne peut pas être n'importe quoi, mais beaucoup. Par exemple, une application mobile qui demande des données au serveur. Ou un navigateur qui envoie des requêtes depuis une page Web à un serveur pour télécharger des données. L'application A peut demander des données à l'application B. Alors A est un client par rapport à B, et B est un serveur par rapport à A. En même temps, A peut traiter les requêtes de C, D, D, etc. Dans ce cas, l’application A est à la fois serveur et client. Cela dépend du contexte. Une chose est claire : le composant qui envoie la requête est le client. Le composant qui reçoit, traite et répond à la demande est le serveur. Cependant, tous les systèmes dont les composants communiquent via requête-réponse ne sont pas des systèmes REST (ou RESTful). Pour qu’un système soit considéré comme RESTful, il doit « s’adapter » à six contraintes REST :
1. Amener l'architecture à un modèle client-serveur
La base de cette limitation est la différenciation des besoins. Il est nécessaire de séparer les besoins de l'interface client de ceux du serveur qui stocke les données. Cette limitation augmente la portabilité du code client vers d'autres plateformes, et la simplification de la partie serveur améliore l'évolutivité du système. La distinction même entre « client » et « serveur » leur permet de se développer indépendamment l'un de l'autre.
2. Manque de condition
L'architecture REST nécessite que la condition suivante soit remplie. Entre les requêtes, le serveur n'a pas besoin de stocker d'informations sur l'état du client et vice versa. Toutes les demandes du client doivent être structurées de manière à ce que le serveur reçoive toutes les informations nécessaires pour compléter la demande. De cette façon, le serveur et le client peuvent « comprendre » n’importe quel message reçu sans se fier aux messages précédents.
3. Mise en cache
Les clients peuvent mettre en cache les réponses du serveur. Celles-ci, à leur tour, doivent être explicitement ou implicitement désignées comme pouvant être mises en cache ou non, afin que les clients ne reçoivent pas de données périmées ou incorrectes en réponse aux demandes ultérieures. Une utilisation appropriée de la mise en cache permet d'éliminer certaines interactions client-serveur, totalement ou partiellement, augmentant ainsi les performances et l'extensibilité du système.
4. Uniformité de l'interface
Les exigences fondamentales de l’architecture REST incluent une interface unifiée et cohérente. Le client doit toujours comprendre dans quel format et à quelles adresses il doit envoyer une demande, et le serveur, à son tour, doit également comprendre dans quel format il doit répondre aux demandes des clients. Il s'agit d'un format unifié pour l'interaction client-serveur, qui décrit quoi, où, sous quelle forme et comment envoyer et constitue une interface unifiée.
5. Couches
Les couches font référence à la structure hiérarchique des réseaux. Parfois, le client peut communiquer directement avec le serveur, et parfois simplement avec un nœud intermédiaire. L'utilisation de serveurs intermédiaires peut augmenter l'évolutivité grâce à l'équilibrage de charge et à la mise en cache distribuée. Donnons un exemple. Imaginons une application mobile populaire dans le monde entier. Sa partie intégrante est le chargement des images. Comme il y a des millions d’utilisateurs, un seul serveur ne pourrait pas supporter une charge aussi lourde. Diviser le système en couches résoudra ce problème. Le client demandera une image au nœud intermédiaire, le nœud intermédiaire demandera l'image au serveur le moins chargé pour le moment et renverra l'image au client. Si la mise en cache est correctement appliquée ici à chaque niveau de la hiérarchie, une bonne évolutivité du système peut alors être obtenue.
6. Code sur demande (restriction facultative)
Cette limitation implique que le client peut étendre ses fonctionnalités en téléchargeant du code depuis le serveur sous forme d'applets ou de scripts.
Les avantages du REPOS
Les applications qui respectent toutes les restrictions ci-dessus présentent les avantages suivants : fiabilité (pas besoin de stocker les informations sur l'état du client, qui peuvent être perdues) ;
performances (dues à l'utilisation du cache) ;
évolutivité ;
transparence du système d'interaction;
simplicité des interfaces ;
portabilité des composants;
facilité d'apporter des modifications ;
la capacité d’évoluer, de s’adapter aux nouvelles exigences.
GO TO FULL VERSION