3. L’architecture d’une API REST

Nous savons maintenant que notre serveur va avoir besoin d’une API REST pour communiquer avec le reste du monde, et que cette API sera de type REST, car cela nous permet de nous baser sur le protocole HTTP. Nous allons donc entrer un peu plus dans les détails de l’architecture d’une API REST, car après tout, nous allons développer une API REST tout au long de ce cours. Il faut donc que nous soyons tout à fait à l’aise avec ce concept. 👍

Heureusement, nous allons voir qu’il n’y a rien de très compliqué, à condition de respecter certaines règles d’or.

Règle d’or n°1 : Orientation Client-Serveur

Les responsabilités sont complétement séparées entre le client et le serveur. Il est impossible qu’ils s’occupent de la même chose.

La partie frontend, également appelé « client », a pour objectif de faire fonctionner l’interface utilisateur. Quant à la partie serveur, elle s’occupe de toutes les tâches nécessaires pour faire fonctionner l’arrière-boutique : stockage des données, répondre aux demandes du client, etc.

L’avantage de ce découpage devient vite évident. Vous pouvez ensuite brancher n’importe quelle application à votre API REST. Vous avez une application web ? Branchez-là à votre API REST. Vous créer une nouvelle application mobile pour Android ? Branchez-là à votre API REST déjà existante. Et pour iOS ? Même réponse !

L’extensibilité de ce système présente donc un avantage certain. Mais peut-être encore plus essentiel, cette séparation permet aux composants d’évoluer indépendamment. Vous pouvez ainsi développer à plusieurs de manière plus rapide, et sans risquer de « casser » quelque chose de l’autre côté.

Règle d’or n°2 : Sans état !

C’est sans doute la règle la plus importante.

La communication entre le client et le serveur s’effectue sans aucune conservation de la part du serveur. C’est assez contre intuitif au premier abord.

Imaginez que vous allez au restaurant. À chaque fois que le serveur vient vous voir, il vous dit « Bonjour, installez-vousje vais prendre votre commande » Vous attendez un peu… et il vous redemande de vous installer : « Bonjour, installez-vousje vais prendre votre commande« . Et ainsi de suite indéfiniment. À chaque fois que vous échanger avec lui, vous reprenez la discussion de zéro.

C’est exactement le même fonctionnement pour le serveur web, cette fois.

L’état de la session doit être conservé par le client ET transmis à chaque nouvelle requête :

« Bonjour, je me suis déjà installé. J’ai d’abord commandé une salade en entrée. Maintenant, je veux le plat principal ! »

À chaque fois que vous vous adressez à votre serveur, vous devez lui rappelez qui vous êtes, et ce que vous souhaitez obtenir. Plus vous êtes précis dans votre demande, plus le serveur vous apportera une réponse qui correspond exactement à ce que vous voulez. Par contre, vous devez lui redonnez les bonnes informations à chaque demande. 🙂

Ce système a l’avantage d’améliorer la visibilité des échanges entre le navigateur et le serveur, puisque vous êtes obligés d’envoyer des requêtes complètes.

De plus, le fait de ne pas avoir à se souvenir des échanges permet au serveur de répondre à d’autres requêtes venant d’autres clients sans saturer. Chaque client fait son boulot, ce qui améliore l’extensibilité du système. Il est plus facile que 1 million de clients face chacun leur travail, plutôt que de demander à un seul serveur de faire le travail de 1 million de clients.

Le fait d’être “sans état” signifie donc que le serveur n’a aucune idée de l’état du client entre deux requêtes. Du point de vue du serveur, chaque requête est une entité distincte des autres, et il les traite en conséquence.

Ces deux règles sont les deux concepts de base à comprendre sur REST.

Nous verrons d’autres éléments lorsque nous seront plus avancé dans nos développements, mais pour le moment nous sommes tout à fait prêt à passer à la suite.