Historique des conversations
Chargement...
Architecture REST et contraintes
REST signifie Representational State Transfer. Ce n'est pas un protocole, mais un style d'architecture défini par Roy Fielding en 2000.
Les 6 Contraintes de REST
Pour qu'une API soit considérée comme véritablement "RESTful", elle doit respecter plusieurs contraintes :
1. Client-Serveur
Séparation des responsabilités. Le client s'occupe de l'interface, le serveur des données.
2. Sans état (Stateless)
Chaque requête du client doit contenir toutes les informations nécessaires. Le serveur ne garde pas de "session" en mémoire.
3. Cacheable
Les réponses doivent indiquer si elles peuvent être mises en cache pour améliorer les performances.
4. Système par couches
Le client ne peut pas dire s'il est connecté directement au serveur de base ou à un serveur intermédiaire (proxy, load balancer).
5. Interface Uniforme
C'est le point clé : utiliser des URI pour les ressources et les verbes HTTP standards.
6. Code à la demande (Optionnel)
Le serveur peut envoyer du code exécutable (ex: JavaScript) au client.
La notion de Ressource
Dans REST, tout est une ressource (un utilisateur, une photo, une commande). Chaque ressource est identifiée par une URI unique (Universal Resource Identifier).
GET https://api.monsite.com/users/42
Ici, la ressource est l'utilisateur avec l'ID 42.
Astuce : Une API REST est dite "stateless", ce qui facilite sa montée en charge (scalability) car n'importe quel serveur peut traiter n'importe quelle requête.