1
Architecture Orientée Service
(SOA)
REST
MME. BENOTMANE.Z
TTN
MODULE: ARCHITECTURE RÉPARTIE
2024/2025
REST-Representational State Transfer
2
REST est un style architectural pour les systèmes
distribués basé sur des protocoles de communication
comme HTTP.
Il repose sur un ensemble de contraintes et de
principes qui facilitent la création de services web
flexibles, performants et évolutifs.
REST utilise des ressources (des données
identifiables par des URLs) et des méthodes
standardisées (comme HTTP) pour effectuer des
opérations sur ces ressources.
Principe de base
3
1-Client-Serveur :
Les clients (navigateurs web, applications mobiles, etc.) et les
serveurs (Backand) sont distincts.
Le client envoie des requêtes au serveur, qui les traite et
répond avec les résultats.
2-Stateless (Sans état) :
Chaque requête du client contient toutes les informations
nécessaires pour être comprise par le serveur.
Le serveur ne garde pas de trace de l'état du client entre les
requêtes.
Principe de base
4
3-Cacheabilité :
Les réponses doivent être explicitement définies comme
pouvant être mises en cache ou non.
Cela permet d'améliorer les performances en réduisant le
nombre de requêtes répétées.
4-Interface uniforme :
REST utilise une interface standardisée pour les
opérations, facilitant l'interopérabilité.
Les méthodes HTTP typiques utilisées sont :
GET : Récupérer une ressource.
POST : Créer une nouvelle ressource.
PUT : Mettre à jour ou remplacer une ressource existante.
DELETE : Supprimer une ressource.
Principe de base
5
Représentation des ressources :
Une ressource est identifiée par une URL unique
(Uniform Resource Locator).
Le client et le serveur communiquent via des
représentations de cette ressource (par exemple,
JSON ou XML).
Système en couches :
Un client n'a pas besoin de savoir si une requête
passe par des serveurs intermédiaires ou directement
au serveur d'origine.
Ressource
6
Une ressource est une représentation d'un objet ou
d'une entité accessible via un URI. Il peut s'agir de
tout élément ou concept faisant partie de
l’application: des comptes, des produits, des articles,
etc.
Une ressource est souvent représentée par une
structure de données (JSON, XML, etc.) et expose
ses informations via un format compréhensible par
le client.
Principe de ressource
7
Identifiabilité : Chaque ressource doit avoir une URL
unique. Par exemple, pour accéder à un utilisateur spécifique
dans un système, l'URL pourrait être /users/123, où 123 est
l'identifiant de l'utilisateur.
Représentation : Une ressource peut être représentée de
différentes manières selon le contexte. Par exemple,
l'utilisateur 123 peut être représenté en JSON ou XML pour
une autre application. L'API REST répond avec la
représentation demandée par le client.
Manipulable par des méthodes HTTP : Les ressources
sont manipulées via les méthodes standard HTTP :GET pour
récupérer une ressource.
POST pour créer une nouvelle ressource.
PUT ou PATCH pour mettre à jour une ressource existante.
DELETE pour supprimer une ressource.
Eenpoint en REST
8
Un endpoint est une URL spécifique (ou URI) qui expose une
ressource ou un ensemble de ressources. Il représente un point
d'accès où les clients peuvent interagir avec les ressources via
des requêtes HTTP.
C'est l'"adresse" que le client utilise pour envoyer des requêtes
et recevoir des réponses.
9
Coté Serveur
2) Conception de l'API :
10
Le développeur côté serveur commence par définir
les ressources que l'API va exposer. Chaque
ressource a un chemin d'accès spécifique (ou
endpoint) comme /users, /produits, etc.
Il écrit les méthodes HTTP qui seront utilisées
pour chaque opération sur ces ressources, telles que
GET pour lire, POST pour créer, PUT/PATCH pour
modifier et DELETE pour supprimer.
2) Création des routes :
11
Le côté serveur met en place des routes qui
correspondent aux endpoints définis. Chaque route
est associée à une opération qui gère les requêtes
spécifiques pour ce chemin.
Par exemple, la route GET /users peut être associée à
une opération qui renvoie la liste des utilisateurs.
3)Réponses et formats des données :
12
Le développeur spécifie les réponses que le serveur
doit envoyer au client, souvent sous forme de
données structurées comme du JSON ou du XML.
Il utilise les codes de statut HTTP appropriés
pour indiquer le résultat de l'opération (par exemple,
200 OK pour une opération réussie, 404 Not Found
pour une ressource inexistante, etc.).
4) Sécurisation et documentation :
13
Le développeur peut ajouter des mécanismes de
sécurité tels que l'authentification et l'autorisation
(via des tokens, des sessions, etc.).
Il rédige la documentation de l'API pour expliquer
comment consommer les différents endpoints, les
paramètres requis, et les formats des réponses. Il
existent plusieurs outils qui peuvent faciliter cette
documentation.
5) Déploiement du service :
14
Une fois que l'API est prête, le développeur déploie le
service sur un serveur. Cela rend l'API accessible via
une URL publique ou privée.
15
Coté Client
1) Compréhension de l'API :
16
Le développeur côté client lit la documentation de
l'API fournie par le backend pour comprendre
comment utiliser chaque endpoint. Cela inclut la
compréhension des méthodes HTTP à utiliser, des
paramètres requis, des codes de statut de réponse et
des formats des données.
2) Création des requêtes HTTP
17
Le client envoie des requêtes HTTP au service
REST pour obtenir ou manipuler les données
nécessaires.
Cela se fait généralement à l'aide d'outils ou de
bibliothèques comme fetch() en JavaScript, …etc
Chaque requête contient l'URL de l'endpoint, la
méthode HTTP et, si nécessaire, des données dans
le corps de la requête (pour les méthodes POST,
PUT, etc.).
3)Traitement des réponses :
18
Le développeur côté client reçoit les réponses du
service REST, généralement sous forme de JSON.
Il extrait les données nécessaires et les utilise pour
son application.
Remarque(l'authentification) :
Si le backend impose des règles d'authentification
ou d'autorisation, le frontend peut inclure des
tokens dans les en-têtes des requêtes (pour prouver
l'identité de l'utilisateur).
19
20
