REST : Representational State Transfer
Infrastructure
REST : Representational State Transfer. « Transfert d'état représentationnel », par analogie avec une bibliothèque où chaque livre a une cote fixe et où l'on ne demande jamais au bibliothécaire de se souvenir de la visite précédente.
Style d'architecture : REST n'est ni un protocole ni un format, mais un ensemble de contraintes décrites par Roy Fielding dans sa thèse : client et serveur séparés, échanges sans état, réponses pouvant être mises en cache, interface uniforme. En pratique, le mot désigne surtout des API construites sur HTTP.
Ressources et verbes : Chaque ressource a son URL, et les méthodes HTTP portent l'intention : GET lit, POST crée, PUT remplace, d'autres suppriment ou modifient partiellement. Les codes de statut disent ce qui s'est passé, du moins quand le serveur consent à dire la vérité.
Sans état : Chaque requête transporte tout ce qu'il faut pour être traitée, jeton d'authentification compris. Le serveur n'a pas à retenir de session, ce qui facilite la répartition de charge.
L'étiquette et le contenu : Bien des interfaces dites REST n'en respectent qu'une partie des contraintes. Le mot figure sur leur documentation comme une appellation prestigieuse sur un vin de table : la bouteille est là, le terroir beaucoup moins.
Ce qui arrive si on s'en passe
Chaque requête d'une API REST transporte son jeton d'authentification : un point d'accès qui ne le vérifie pas à chaque appel laisse donc passer la requête de n'importe qui. Une ressource que son URL suffit à atteindre, sans contrôle que le demandeur y a droit, se lit en changeant simplement un identifiant dans l'adresse. Un GET qui modifie des données se fait déclencher par un lien piégé, voire par un robot d'indexation de passage. Oublier enfin l'absence d'état conduit à des serveurs qui retiennent une session implicite, que le répartiteur de charge envoie consulter ailleurs. L'appellation prestigieuse ne garantit pas le terroir, ni d'ailleurs que la cave soit fermée à clé.
Explication de la marmotte
Quand une application sur un téléphone affiche la météo, elle demande les informations à un serveur distant. Cette façon d'organiser les échanges propose des règles de bon sens : chaque information a sa propre adresse, comme un livre a sa place sur une étagère, et chaque demande utilise un petit nombre d'actions connues de tous, comme lire, ajouter, remplacer ou effacer. Surtout, chaque demande se suffit à elle-même : le serveur n'a pas besoin de se rappeler la conversation précédente. Cela permet de répartir le travail entre de nombreuses machines sans rien perdre.
Où ce terme est utilisé
- Sécuriser les extensions tierces WordPress (3 occurrences)
- Comment sécuriser une API GraphQL en production (2 occurrences)
- Gestion réseau, supervision et référentiels d’exploitation (1 occurrence)
- IoC ou TTP pour détecter une compromission (1 occurrence)
- La règle 3-2-1 à l'épreuve du rançongiciel (1 occurrence)