« REST » ne veut pas dire ce que vous croyez

« On fait du REST. » La phrase clôt plus de débats d'architecture qu'elle n'en ouvre, et elle désigne presque toujours la même chose : du JSON renvoyé sur HTTP, avec des verbes et de jolies URL. C'est une définition de commodité — et elle passe à côté de presque tout ce que REST voulait dire.

On parle de REST comme d'une technologie : un protocole, un format, une recette à suivre. Dans son texte fondateur, il n'est rien de tout cela. REST — REpresentational State Transfer — est un style architectural : non pas une implémentation, mais un ensemble de contraintes qui, composées, confèrent à un système réparti des propriétés précises. Roy Fielding l'a formulé en 2000 dans sa thèse de doctorat. Détail qui change tout : il ne l'a pas plaqué après coup sur HTTP. Fielding est l'architecte principal de HTTP/1.1 et co-auteur des spécifications d'URI ; sa thèse met un nom — REST — sur les contraintes qu'il avait lui-même inscrites dans les protocoles du Web. Le style ne se pose pas sur HTTP : HTTP a été façonné par le style.

Un style, pas une technologie

Un style architectural ne dit pas avec quels outils construire ; il dit à quelles règles se plier, et ce qu'on gagne à s'y plier. HTTP est une implémentation du style REST, la plus connue — mais REST ne se confond ni avec HTTP, ni surtout avec « HTTP + JSON ». La preuve par les deux bords : on peut parfaitement faire du non-REST en HTTP — le RPC (appel de procédure distante : invoquer une fonction sur un serveur lointain comme si elle était locale), déguisé en requête web à la manière des services SOAP, en est l'exemple type — et faire du REST sans JSON : le Web, justement, sert d'abord du HTML.

Réduire REST à un couple « verbes + JSON », c'est donc une erreur de catégorie : on confond un cas particulier avec le principe. Et la confusion a un coût, car elle escamote la moitié des contraintes — celles qui ne se voient pas dans le corps d'une réponse, mais qui font tout le travail.

Six contraintes, six propriétés

Un style se définit par les contraintes qu'il impose. REST en compte six, et chacune renonce à une liberté pour gagner une propriété concrète :

• Client-serveur — séparer l'interface utilisateur du stockage des données, pour les faire évoluer indépendamment, chacun de son côté.
• Sans état (stateless) — chaque requête transporte tout son contexte ; le serveur ne retient rien entre deux appels. C'est ce qui autorise à placer mille serveurs interchangeables derrière une seule adresse et à router n'importe quelle requête vers n'importe lequel : la mise à l'échelle horizontale.
• Cacheable — une réponse se déclare réutilisable, ou non, via ses en-têtes (Cache-Control, ETag). Des intermédiaires — du cache du navigateur jusqu'au CDN — peuvent alors répondre à la place du serveur. Ce n'est pas un réglage de performance, mais un levier d'évolutivité.
• Interface uniforme — nommer et manipuler toute ressource de la même façon, quel que soit son type. C'est la contrainte centrale, la clé de voûte ; le prochain volet lui est consacré.
• Système en couches — proxies, caches et passerelles de sécurité s'intercalent sans que le client ni le serveur le sachent. Un reverse-proxy, un pare-feu applicatif, un répartiteur de charge n'existent que grâce à cette contrainte.
• Code à la demande (la seule facultative) — le serveur peut envoyer au client du code à exécuter, le JavaScript d'une page web par exemple, pour étendre ses capacités après coup.

Aucune de ces contraintes, prise isolément, n'a rien de remarquable : c'est leur composition qui fait le style. Renoncer à l'état serveur coûte — il faut renvoyer le contexte à chaque requête — mais c'est ce renoncement qui achète l'échelle ; rendre une réponse cacheable oblige à expliciter sa fraîcheur, mais décharge le serveur d'autant. Un style, c'est exactement ce faisceau de compromis assumés ensemble, parce qu'ensemble ils achètent une qualité qu'aucun n'obtient seul.

Une petite histoire des années REST

Le mot a une histoire, et elle éclaire le malentendu : REST n'est pas né dans le vide, il a grandi avec le Web. Tout commence en 1991, quand Tim Berners-Lee met en service au CERN le premier serveur web et un HTTP minimal — HTTP/0.9, une seule commande, GET. Le protocole se formalise en 1996 (HTTP/1.0), puis en 1999 avec HTTP/1.1, dont Fielding est l'architecte principal : c'est là que la mise en cache, l'absence d'état et l'interface uniforme deviennent des règles écrites. En 2000, sa thèse leur donne un nom — REST. Le style ne précède pas le Web ; il en est la théorie, formulée après coup.

Durant la première moitié des années 2000, REST sert surtout d'argument. Face aux « services web » lourds de l'époque — SOAP et la pile WS-*, soit du RPC empaqueté dans du XML —, il incarne l'alternative simple : des ressources, des URL, les verbes HTTP. Le basculement grand public date de 2007 : le livre RESTful Web Services (Richardson et Ruby, O'Reilly) en donne la première synthèse, Ruby on Rails 1.2 câble les routes « RESTful » dans un framework massivement adopté, et Java lance la spécification JAX-RS. C'est là que l'expression « API REST » s'installe — et, avec elle, le glissement de sens.

Car dès 2008, Fielding doit publier une mise au point restée célèbre pour rappeler ce que la mode oubliait déjà — on y reviendra au troisième volet ; la même année, Leonard Richardson propose un « modèle de maturité » pour mesurer les degrés de RESTfulness. Les années 2010 généralisent l'« API REST » comme contrat par défaut des back-ends web et mobiles — Spring, JAX-RS, Django REST framework (2011), ASP.NET Web API (2012) — et le JSON détrône le XML. Mais la contrainte la plus exigeante, l'hypermédia, reste massivement laissée de côté ; ce vide explique en partie l'essor de GraphQL (2015) et de gRPC (2015), venus combler ce qu'un demi-REST laissait béant. Puis, dans les années 2020, l'hypermédia revient par la porte qu'il n'aurait jamais dû quitter — celle du HTML (le mouvement htmx, le livre Hypermedia Systems en 2023).

La leçon de cette chronologie tient en une phrase : le sens du mot s'est rétréci à mesure qu'il se répandait. L'« API REST », née vers 2007, est une vulgarisation qui a retenu les ressources et les verbes, et laissé filer le reste.

L'architecture qui existait déjà

Reste l'observation qui résume tout. Bien avant le label, le Web était l'incarnation pleine du style — et il l'est encore. Un unique client générique, le navigateur, dialogue avec des milliards de serveurs qu'il n'a jamais rencontrés, sans être recompilé pour aucun, parce que chaque réponse lui indique elle-même ce qu'il peut faire ensuite : les liens à suivre, les formulaires à soumettre. Aucune « API REST » au sens courant n'offre cela — son client, lui, doit connaître l'application à l'avance et coder ses URL en dur.

C'est dans ce contraste que se loge le cœur de REST : l'interface uniforme et, en son centre, l'hypermédia. C'est elle qui sépare un client capable de durer trente ans d'un client jetable qu'il faut réécrire à chaque changement d'URL. Elle mérite son propre volet — c'est l'objet du prochain article.