Présentation de REST. Partie 1 : Qu'est-ce que REST ?

Salut! Aujourd'hui, nous allons en apprendre davantage sur un sujet très intéressant et, surtout, très demandé sur le marché du travail : REST. Nous diviserons notre aperçu de REST en trois parties :

1. Dans la première partie, nous couvrirons l'histoire de REST et décrirons les principes sur lesquels repose REST.

2. Dans la seconde, nous examinerons comment la communication entre un client et un serveur se produit via le protocole HTTP.

3. Dans le troisième, nous allons écrire une petite application RESTful que nous testerons à l'aide d'un programme appelé "Postman".

L'article est destiné aux lecteurs familiarisés avec les termes suivants :

• HTTP
• URL et URI
• JSON et (dans une moindre mesure) XML
• Injection de dépendance

Partie 1. Qu'est-ce que REST ?

REST, comme tant d'autres dans le monde informatique, est un acronyme. Il est dérivé de "REpresentational State Transfer" . Il s'agit d'un style architectural pour l'interaction entre les composants d'un système distribué dans un réseau informatique. En termes simples, REST détermine le style d'interaction (échange de données) entre les différents composants du système, chacun pouvant être physiquement situé à différents endroits. Ce style architectural est un ensemble cohérent de contraintes respectées lors de la conception d'un système distribué. Ces contraintes sont parfois appelées les principes directeurs de REST. Il n'y en a pas beaucoup, seulement 6. Nous en reparlerons un peu plus tard.

Histoire de REST

Le terme REST a été introduit par Roy Fielding, l'un des créateurs du protocole HTTP, dans son doctorat. thèse intitulée "Architectural Styles and the Design of Network-based Software Architectures" en 2000. Bien que le terme REST puisse encore être qualifié de jeune, le concept qu'il représente est au cœur même du World Wide Web. Nous n'approfondirons pas l'histoire du terme. Si vous souhaitez vous plonger dans les sources primaires, jetez un œil à la thèse de Fielding .

Contraintes 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 par le biais d'un processus de demande-réponse. Le composant qui envoie la requête s'appelle le client , et le composant qui traite la requête et envoie une réponse au client s'appelle le serveur. Les requêtes et les réponses sont le plus souvent envoyées via le protocole HTTP. HTTP signifie HyperText Transfer Protocol. En règle générale, un serveur est une application Web. Le client peut être presque n'importe quoi. Par exemple, une application mobile qui demande des données à un serveur. Ou un navigateur qui envoie des requêtes d'une page Web à un serveur afin de télécharger des données. L'application A peut demander des données à l'application B. Dans ce cas, A est un client par rapport à B et B est un serveur par rapport à A. En même temps, A pourrait traiter les demandes de B, C, D, etc. Dans ce cas, l'application A est à la fois serveur et client. Tout dépend du contexte. Une chose est sûre : le composant qui envoie la requête est le client. Le composant qui reçoit, traite et répond à une requête est le serveur. Cependant, tous les systèmes dont les composants communiquent via un processus de demande-réponse ne sont pas des systèmes RESTful. Pour qu'un système soit considéré comme RESTful, il doit respecter les six contraintes REST :

1. Architecture client-serveur

Cette contrainte concerne la séparation des préoccupations. Il est nécessaire de séparer les exigences de l'interface client des exigences du serveur qui stocke les données. Cette contrainte rend le code client plus portable vers d'autres plates-formes, et la simplification du côté serveur améliore l'évolutivité du système. La distinction entre le "client" et le "serveur" permet de les développer indépendamment l'un de l'autre.

2. Apatride

Une architecture RESTful nécessite que les conditions suivantes soient remplies. Dans la période entre les requêtes, le serveur ne doit pas stocker d'informations sur l'état du client et vice versa. Toutes les demandes du client doivent être composées de manière à donner au serveur toutes les informations nécessaires pour compléter la demande. Ainsi, le serveur et le client peuvent "comprendre" n'importe quel message reçu, sans se fier aux messages précédents.

3. Cacheable

Les clients peuvent mettre en cache les réponses du serveur. Ceux-ci, à leur tour, doivent explicitement ou implicitement être désignés comme mis en cache ou non mis en cache, afin que les clients ne reçoivent pas de données obsolètes ou incorrectes en réponse aux demandes ultérieures. Une mise en cache correcte permet d'éliminer complètement ou partiellement certaines interactions client-serveur, augmentant encore les performances et l'évolutivité du système.

4. Interface uniforme

Les exigences fondamentales d'une architecture RESTful incluent une interface unifiée et uniforme. Le client doit toujours comprendre le format et les adresses qu'il doit utiliser lors de l'envoi d'une demande, et le serveur, à son tour, doit également comprendre le format qu'il doit utiliser pour répondre aux demandes du client. Cette interaction client-serveur cohérente qui décrit quoi, où, sous quelle forme et comment envoyer des données est une interface unifiée.

5. Couches

Par couches, nous entendons la structure hiérarchique du réseau. Parfois, un client peut communiquer directement avec le serveur, et parfois il communique 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. Imaginez une application mobile populaire dans le monde entier. Une partie intégrante de l'application consiste à charger des images. Ses utilisateurs se comptent par millions, de sorte qu'un seul serveur ne peut pas gérer une charge aussi lourde. Séparer le système en couches résoudra ce problème. Si le client demande une image à un nœud intermédiaire, alors le nœud intermédiaire demande l'image au serveur qui est le moins chargé à ce moment et renvoie l'image au client. Si la mise en cache est correctement appliquée à chaque niveau de la hiérarchie,

6. Code à la demande (optionnel)

Cette contrainte 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.

Avantages d'une architecture RESTful

Les applications qui respectent toutes les contraintes précitées présentent les avantages suivants : fiabilité (pas besoin de sauvegarder l'état du client, qui pourrait être perdu)

• performances (grâce à l'utilisation d'un cache)
• évolutivité
• communication transparente
• interfaces simples
• portabilité
• capacité à faire des changements facilement
• capacité à évoluer et à s'adapter aux nouvelles exigences

Présentation de REST. Partie 2 : Communication entre un client et un serveur Présentation de REST. Partie 3 : Création d'un service RESTful sur Spring Boot