Principes REST

Les contraintes d'une architecture REST : sans état, client/serveur, représentations multiples, et comparaison avec RPC et GraphQL.

REST (Representational State Transfer) n'est pas un standard mais un style d'architecture défini par Roy Fielding. Une API « REST » respecte un ensemble de contraintes qui la rendent prévisible et scalable.

📜 Les contraintes clés

Client / Serveur : séparation nette. Le client gère l'interface, le serveur les données.
Sans état : chaque requête contient tout le contexte nécessaire. Le serveur ne stocke rien sur la session.
Cacheable : les réponses indiquent si elles peuvent être mises en cache.
Interface uniforme : on manipule des ressources par leur URL et les méthodes HTTP.
Représentations : une même ressource peut être servie en JSON, XML, etc. via l'en-tête Accept.

Le « sans état » est la contrainte la plus importante : si le serveur redémarre, aucune session client n'est perdue, car rien n'était stocké côté serveur.

🔄 Client / Serveur et sans état

GET /articles/42 HTTP/1.1
Accept: application/json
Authorization: Bearer ***   # le contexte voyage dans la requête

Chaque requête doit pouvoir être traitée sans se souvenir des précédentes.

🧾 Représentations multiples

La même ressource /articles/42 peut être renvoyée en JSON ou XML selon l'en-tête demandé.

GET /articles/42
Accept: application/xml     # → représentation XML

🆚 REST vs RPC vs GraphQL

Style	Idée	Force	Faiblesse
REST	Ressources + verbes HTTP	Simple, cacheable, prévisible	Sur-/sous-requêtage possible
RPC	Appel de fonctions distantes	Proche du code procédural	Moins uniforme
GraphQL	Requête déclarative	1 appel, données exactes	Serveur plus complexe

RPC (ex. gRPC) est idéal pour la communication interne entre services ; REST brille pour des API publiques et cacheables ; GraphQL quand le client veut façonner sa réponse.

➡️ Suite

La page Ressources et URLs montre comment nommer concrètement les ressources.

API REST

Terminez le quiz du chapitre pour le marquer comme complété.

Tableau de bord