Les principes fondamentaux de REST

Les règles du jeu, écrites dans le béton

4.1 Client–Serveur

Une frontière nette.
Le client s’occupe de l’interface, de l’expérience, de l’état utilisateur.
Le serveur gère les données, la logique métier, la persistance.
Chacun dans son rôle, séparés par le réseau.
Cette séparation permet à chacun d’évoluer de son côté. Le serveur change sans que le client ne le sache. Le client se réinvente sans toucher au serveur. Une indépendance froide, efficace.

4.2 Stateless (sans état)

Aucune mémoire côté serveur.
Chaque requête doit apporter avec elle tout ce qu’il faut pour être comprise : identité, contexte, permissions.
Pas de sessions traînantes, pas de baggage entre deux appels.
Le serveur traite, répond, oublie.
Avantage : scalabilité facile. On peut ajouter des serveurs sans se soucier de synchroniser des sessions. Tolérance aux pannes : si un serveur tombe, le suivant peut prendre le relais sans rien savoir du passé.

4.3 Cache

Certaines réponses peuvent être stockées temporairement, côté client ou dans un proxy.
Cache-Control, Expires, ETag.
Le cache allège la charge du serveur, accélère les réponses.
Mais il introduit un risque : des données périmées, figées dans le temps.
Il faut marquer clairement ce qui peut être mis en cache, et pour combien de temps.

4.4 Uniform Interface

C’est le cœur de REST.
Une façon uniforme d’accéder aux ressources, partout, toujours.

• Identification des ressources via des URI :
  /clients/52, /commandes/2024-001. Chaque ressource a une adresse unique.
• Manipulation via les méthodes HTTP :
  GET pour lire, POST pour créer, PUT pour remplacer, DELETE pour supprimer.
  Une grammaire simple, universelle.
• Représentations :
  Le serveur renvoie une représentation de la ressource (JSON, XML, etc.). Le client la consomme, parfois la modifie et la renvoie.
• Messages auto-descriptifs :
  Chaque requête et réponse contient assez de métadonnées pour être comprise seule.

4.5 Layered System

Le client ne sait pas à combien de couches il a affaire.
Il envoie une requête à une adresse, point.
Derrière, il peut y avoir un load balancer, un proxy, un firewall, un serveur d’authentification, une base de données.
Chaque couche ajoute une fonction, sans que le client ne le voie.
Cela amène de la flexibilité, de la sécurité, de la performance.
Mais aussi de l’opacité. On ne sait jamais vraiment par où passent les données.

Ces cinq principes forment un système.
Sans état, en couches, avec une interface uniforme et du cache là où c’est possible.
C’est ce qui donne à REST sa résilience, sa capacité à s’étendre sans se rompre.
Une architecture sans pitié, mais qui tient la route.