Polar Code 🎭

Command Palette

Search for a command to run...

03
Pièce N°03

Origine et définition de REST

Un style architectural né dans les couloirs de la thèse


REST : Representational State Transfer
Un nom lourd, une idée simple.
Ce n’est pas un protocole, pas une technologie.
C’est une philosophie.
Une manière de concevoir les interactions entre client et serveur pour qu’elles restent légères, claires, sans mémoire.


Roy Fielding (thèse de 2000)
Tout vient de là.
En 2000, Roy Fielding, l'un des pères d’HTTP, pose les bases dans sa thèse de doctorat.
Il ne cherchait pas à inventer un nouveau standard, mais à décrire ce qui rend le Web scalable, simple, résilient.
REST, c’est l’ADN architectural du Web, formalisé.


REST comme style architectural, pas une technologie
On parle souvent d’« API REST », mais c’est un abus de langage.
REST n’est ni un langage, ni un framework.
C’est un ensemble de contraintes, une façon de penser les systèmes distribués.
Le vrai nom serait : une API conforme aux principes REST.
Beaucoup s’en réclament… peu les respectent jusqu’au bout.


Objectifs de REST
Fielding avait en tête plusieurs buts, tous tournés vers la robustesse à grande échelle :

  • Scalabilité : supporter des millions de clients sans s’effondrer.
    Pas de sessions côté serveur, pas d’état stocké inutilement.

  • Simplicité : des interfaces uniformes, prévisibles.
    On utilise ce qui existe déjà – HTTP, URIs – sans rien réinventer.

  • Interopérabilité : n’importe quel client, n’importe quelle plateforme.
    Du moment qu’il parle HTTP et comprend les représentations (JSON, XML…), il peut communiquer.

  • Indépendance client/serveur : chacun évolue de son côté.
    Le client n’a pas besoin de connaître la logique métier du serveur.
    Le serveur ne se soucie pas de l’interface utilisateur.


REST, c’est une architecture de l’oubli.
Le serveur ne se souvient de rien, le client porte l’état.
Chaque requête contient tout ce qu’il faut pour être comprise.
C’est ce qui le rend solide.
Et ce qui le rend froid.