REST et l’approche orientée

ressource

1
Un mot sur les services Web REST
• Exploités pour les Architectures Orientées Données
(DOA)
• REST n’est pas un standard, il n’existe pas de
spécification W3C définissant une spécification
• REST est un style d’architecture basé sur un mode de
compréhension du Web
• REST s’appuie sur des standards du Web :
– Protocole HTTP
– URIs
– Formats de fichiers
– Sécurisation via SSL

2
 Approche Orientée Ressources ou
REST
• REST est l’acronyme de REpresentational State Transfert
• Ses principes ont été définis dans la thèse de Roy FIELDING
en 2000
– L’un des principaux auteurs des spécifications de HTTP
– Membre fondateur de la fondation Apache
– Développeur du serveur web Apache
• REST est un style d’architecture inspiré de l’architecture du
web
• C’est donc
– Une manière de construire une application
• Et ce n’est pas
– Un format, un protocole, un standard

3
 C’est quoi REST?
• Les Services Web REST sont utilisés pour développer
des architectures orientées ressources
• Différentes dénominations disponibles dans la
littérature
– Architectures Orientées Données (DOA)
– Architectures Orientées Ressources (ROA)
• Les applications qui respectent les architectures
orientées ressources sont respectivement nommées
RESTful
• Dans la suite du cours nous utiliserons indifféremment
la dénomination REST et RESTful
4
 Caractéristiques de REST
• Les services Web REST sont sans états (Stateless)
– Le serveur n’a jamais à connaître l’état du client et réciproquement
– Le client maintient l’état de l’application de son point de vue
– Le serveur fait de même en maintenant l’état de ses ressources
➔Ces états ne sont jamais partagés !!!

– Tout changement d’état a lieu à la suite d’un échange de messages

entre client et serveur ➔transfert de représentations
– Vu que serveur et client ne connaissent pas leurs états respectifs
• Chaque requête envoyée vers le serveur doit contenir toutes les informations
nécessaires à son traitement
• Le serveur ne conserve aucune information sur les clients
➔Minimisation des ressources systèmes, pas de session ni d’état

5
 Caractéristiques de REST
• Les services Web REST fournissent une interface uniforme
basée sur les méthodes HTTP
– GET, POST, PUT et DELETE
• Les architectures orientées REST sont construites à partir
de ressources qui sont uniquement identifiées par des URIs

Recommandation:
Les traitements doivent être pensés côté
client et non pas côté serveur

6
 L’architecture orientée ressource
repose sur 3 concepts …
• Ressource (Identifiant)
– Identifiée par une URI
– Exemple :
[Link]
• Méthode (Verbe)
– Permet de manipuler l’identifiant ou la ressource
– Méthodes HTTP : GET, POST, PUT et DELETE
• Représentation donne une vue d’une ressource
– On parle souvent de la vue de l’état d’une ressource
– C’est l’information transférée entre le client et le serveur
– Exemple : XML, JSON
7
 … et 4 propriétés
• Les représentation doivent être adressables
• Les services doivent être sans état
• Les services / ressources doivent être
connectés
• Les services respectent une interface uniforme
(Uniform Interface ou UI)

8
 Ressources et URI (1/3)
• Une ressource est quelque chose qui est
identifiable dans un système
– Personne, Agenda, Document, Ensemble, Carte

• [Link]
• [Link]

9
 Ressources et URI (1/3)
• Une ressource est quelque chose qui est identifiable dans un système
– Personne, Agenda, Document, Ensemble, Carte
Mauvaise URI
• [Link]
Bonne URI
• [Link]

D’un point de vue architecture

• Première solution = choix d’implémentation
– ici l’appel de méthode sur un service distant
– HTTP simplement utilisé comme transport de message uniquement
• Seconde solution
– Moins l’impression d’invoquer une opération distante
– URL qui traduit un concept : un étudiant
– ET aucune action

10
 Ressources et URI (2/3)
• Une ressource est quelque chose qui est identifiable dans un système
– Personne, Agenda, Document, Ensemble, Carte
• Une URI identifie une ressource de manière unique sur le système
– Attention, une ressource peut avoir plusieurs URIs
– La représentation de la ressource n’est pas liée à l’URI, elle peut évoluer avec le temps et le
client
– Une URI doit être descriptive (thèse Fielding, recommandations W3C)
– Une URI doit avoir une structure

11
Ressources et URI (3/3)

12
 Méthodes CRUD
• Une ressource peut subir quatre opérations de base désignées par le
terme CRUD pour
– Create – Créer
– Retrieve – Lire
– Update – Mettre à jour
– Delete – Supprimer
• REST s’appuie sur le protocole HTTP pour exprimer directement ces 4
opérations de base via les méthodes de HTTP
– Create par la méthode POST
– Retrieve par la méthode GET
– Update par la méthode PUT
– Delete par la méthode DELETE
➔Peu de verbes pour être standard, interopérable

• Des possibilités supplémentaires peuvent être exprimées via d’autres

méthodes HTTP (HEAD, OPTIONS)

13
 La représentation (1/2)
• Fournir les données suivant une représentation pour
– le client (GET)
– le serveur (PUT et POST)
• Les données retournées le sont sous différents formats
– XML
– JSON
– (X)HTML
– CSV
– ...
• Le format d’entrée (POST) et le format de sortie (GET)
d’un service Web d’une ressource peuvent être
différents
14
 La représentation (2/2)
• Exemples : formats JSON et XML

15
 L’architecture orientée ressource
repose sur 4 propriétés
• Les représentation doivent être adressables
• Les services doivent être sans état
• Les services / ressources doivent être
connectés
• Les services respectent une interface uniforme
(Uniform Interface ou UI)

16
 Propriété 1 – Une représentation
devrait être adressable
• Un service web est adressable dès lors qu’il expose certaines de ses
données sous forme de ressources visibles
– cf. annotation @Path des classes java visibles en Jersey
• Une URI ne doit jamais représenter plus d’une ressource (sinon plus
d’universalité)
Exemple : Une ressource accessible en anglais et en français
• Solution fréquemment utilisé une URI ➔une représentation
– [Link]/2012/books/en  une représentation en anglais
– [Link]/2012/books/fr  une représentation en français
• Autre solution
– [Link]/2012/books/  une seule URI
– Les deux représentations existent toujours (2 méthodes annotées GET avec
des @Produces différents)
– Au client de choisir avec le Accept-Language du header de la requête

Les deux solutions sont RESTful. On ne traite que d’URI, de

représentation et tout passe dans le header de la requête
17
Propriété 2 – Un service est sans état
(1/7)
Toute requête HTTP doit pouvoir s’exécuter de
manière totalement isolée

• Quand un client fait une requête HTTP,

– Toutes les informations nécessaires à l’exécution de la
requête par le serveur sont envoyés au serveur
– Le serveur ne réutilise jamais d’information provenant
de requêtes précédentes
• En pratique, on transfert les informations via les
adresses (URIs)
18
 Propriété 2 – Un service est sans état
(2/7)
Soyez sans état
• Une application Web doit scaler / passer à l’échelle
– Des clusters de serveurs avec gestion de l’équilibrage de charges, des proxys, des points
d’entrées forment des topologies permettant aux requêtes de circuler entre serveurs 
ceci afin de réduire les temps de réponse pour le client
– Ceci implique de pouvoir transférer des requêtes indépendantes et complètes, i.e. des
requêtes autoportantes ➔ l’état ne doit pas être propre au serveur
– Un requête autoportante ne doit donc stocker/utiliser aucune information sur le serveur
qui lui soit propre
• Un service Web REST inclut dans le header et le corps de la requête
HTTP tout ce qui est nécessaire au fonctionnement du service appelé
– Paramètres, contexte, données nécessaires au serveur

• Etre sans état simplifie la conception et l’implémentation des services

côté serveur car l’absence d’état supprime le besoin de synchroniser
des données de la session avec une application externe.

19
 Propriété 2 – Un service est sans état
(3/7)
Exemple d’une Solution avec état
• Une application demande une « page suivante » dans un ensemble
de plusieurs pages résultat
• Avec la notion d’état
– On suppose que le service conserve la trace de la dernière page visitée
– Pour cela, le service incrémente et conserve une variable
previousPage pour pouvoir passer à la page suivante ensuite.
• Une telle variable pose problème à mettre à jour entre plusieurs
serveurs Java (EJC ou servlet/Java Server Pages par ex. avec
[Link] lors de réplication de session.
• En outre la synchronisation de sessions ajoute un surcoût qui
impacte les performances du serveur.
• Enfin, quid de l’idempotence??

20
 Propriété 2 – Un service est sans état
(4/7)
Exemple d’une Solution sans état
• Dans le cas d’un service Web REST, le serveur est responsable de générer
uniquement des réponses
• Le client gère l’état de l’application lui-même
• Dans notre exemple, c’est le client qui indique la page qu’il désire et non pas le
serveur qui en a la connaissance !!!
• En outre, le service Web indique dans la réponse la page suivante au client et
laisse le client gérer cette valeur

21
 Propriété 2 – Un service est sans état
(5/7)
Bonnes Pratiques
• Côté Serveur
– Génère des réponses qui incluent des liens sur d’autres ressources pour
permettrea aux applications clientes de naviguer vers ces ressources
– Génère des réponses qui indiquent si elles sont « cacheables » ou non pour
améliorer les performances en réduisant le nombre de requêtes par
duplication des ressources ou par élimination complète de requête)
• Cache-Control et Last-Modified (valeur de date) HTTP header.
• Côté Client
– Utilise la valeur de Cache-Control du header de la réponse pour déterminer si
la réponse peut être copiée localement ou pas
– Le client lit aussi la valeur Last-Modified du header de la réponse et renvoit la
valeur si la valeur du If-Modified-Since header a changé (appelé GET
conditionnel)
• Un code 304 (Not Modified) indique que la ressource actuelle n’a pas changé
• Le client peut utiliser sa copie local de la ressource tant que la ressource est à jour
– Envoie des requêtes autoportantes.

22
 Propriété 2 – Un service est sans état
(6/7)
• Un service sans état n’impacte qu’un type d’état
• Pour rappel, il existe 2 types d’états dans un service REST
– L’état de la ressource est l’information relative à la ressource
– L’état de l’application est l’information relative à chaque client
• L’état de l’application peut apparaître quand on ne s’y
attend pas
– De nombreux sites web crée des clés uniques pour chaque
utilisateur enregistré
– Cette clé est envoyée avec chaque requête (limitation du
nombre de requête par jour / droit d’accès)

23
 Propriété 2 – Un service est sans état
(7/7)
De l’importance d’être sans état
Permet de passer à l’échelle par
• la mise en cache de ressource
• Par la séparation des requêtes à traiter entre plusieurs
serveurs
– Si un serveur ne peut pas tout traiter, puisque les services sont
indépendants, sans états, on les répartit entre différents
serveurs (équilibrage de la charge de manière aléatoire, round-
robin, etc. )
– Si deux serveurs ne suffisent pas, on en ajoute un troisième, etc.
– Si un serveur tombe, les autres prennent le relais (tolérance aux
pannes)
• Aucune réplication de l’état de l’application

24
 Propriété 3 – Les ressources doivent
être connectées
• Le serveur peut guider le client d’une ressource à
une autre en lui envoyant des liens vers d’autres
resssources dans les réponsesaux requêtes
– Hypermedia as the engine of application state
(Fielding’s PHD thesis)
• C’est le cas du « web humain » où des liens vers
d’autres pages sont présents dans quasiment
toutes les pages webs
• Au contraire le « web programmable » est peu
connecté

25
 Propriété 4 – L’UI (Uniform Interface)
est respectée
• Toutes les interactions entre le client et le serveur passe par l’UI
– GET
– HEAD
– PUT
– DELETE
– POST
• OPTIONS
• Si jamais vous voulez une autre opération, surchargez l’opération
POST
• Mais c’est probablement plutôt une nouvelle ressource à ajouter
• Importance de la sureté et de l’idempotence
– Attention pas pour le POST
• Importance d’utiliser la même interface que tout le monde avec la
même sémantique d’opération !!!

26