Vous êtes sur la page 1sur 86

REST REpresentational State

Transfert
Vers les architectures orientées
ressources

Walid GAALOUL
Plan

1. Architecture du Web – quelques notions


2. Rappels sur HTTP
3. Le modèle de maturité de L. Richardson
4. Comprendre les services Web REST?

Département Informatique
Partie 1
Architecture du web
Quelques notions

Département Informatique
Composants du Web : Pare-feu, routeur,
cache

 Pare-feu
• ces composants décident de l’entrée et de la sortie de
messages HTTP
• Ils renforcent/participent à la sécurité
 Routeur
• Ces composants participent à diriger les messages HTTP
• Ils gèrent le passage à l’échelle
 Caches
• Ces composants décident si la copie d’un message/d’une
donnée doit être effectuée
• Ils améliorent la vitesse
 Tous ces composants basent leurs décisions uniquement
sur le contenu des en-têtes des messages HTTP

Département Informatique
Les composants du Web et l’en-tête des
message HTTP

 Tous ces composants basent leurs décisions uniquement


sur le contenu des en-têtes des messages HTTP

Analogie avec une lettre – courrier postal:


1. Personne à part le destinataire d’une lettre ne doit en
lire le contenu
2. Seul l’extérieur, i.e. l’en-tête, doit être accessible et
les décisions d’acceptation (pare-feu), de redirection
(routeur) et de conservation d’une copie (cache) sont
prises en fonction de cet en-tête uniquement
Département Informatique
Qu’est-ce que le Web 2.0?

 Dépend de celui à qui vous demandez, mais on retiendra


principalement:
 Le Web mature
• Cela marche vraiment maintenant (cf utilisation de AJAX)
- Exemple de Google maps: accès interactif à une vaste base de données (cartes, street
views)
- AJAX rend les navigateurs plus “intelligent” a accès aux serveurs web sous forme de
service
 Le Web programmable
 L’utilisation de Javascript permet d’aller encore plus loin
• Mise à jour partielle de pages web sans tout recharger
 Des applications classiques peuvent communiquer avec des
applications/services web
• Flickr uploader, mise à jour/synchronisation de calendriers
 Les applications Web peuvent discuter
• Import d’amis Facebook dans LinkedIn
 Mashups – composition simple de services

Département Informatique
Partie 2
Rappels sur HTTP

Département Informatique
HyperText Transfert Protocol

 HTTP permet d’accéder aux fichiers situés sur le réseau Internet. Il est
notamment utilisé pour le World Wide Web
 HTTP se place au dessus de TCP et fonctionne selon un principe de
requête/réponse
• le client transmet une requête comportant des informations sur le document
demandé
• le serveur renvoie le document si disponible ou, le cas échéant, un message
d’erreur.

HTTP est un protocole synchrone initialement sans connexion et chaque


couple requête/réponse est de ce fait indépendant.

Département Informatique
HTTP – Bref historique

 De HTTP 1.0 à HTTP 1.1


 Protocole au CERN au début des années 1990 afin
de fournir au Web un protocole de transfert
simple.
 Deux versions du protocole existent :
• HTTP 1.0 définit en 1996 par la RFC 1945
• HTTP 1.1 définit en 1999 par la RFC 2616
 La version 1.1 apporte, entre autre, les
améliorations suivantes :
• Cinq nouvelles méthodes
• Connexions persistantes

Département Informatique
« Adresses » HTTP

 Uniform Resource Identifier URI


• chaîne de caractères structurée permettant d’identifier de
manière unique une ressource dans un espace de nom
défini
• Cette ressource peut être désignée soit par un URN, soit par
un URL
• URN et URL sont des sous-ensembles de URI.
 Uniform Resource Name ou URN
• permet d’identifier une ressource par son nom même
lorsque celle ci n’est plus disponible.
 Uniform Resource Locator ou URL
• permet de localiser une ressource.
• Dans le cas du protocole HTTP, une URL permet de localiser
une page HTML, un fichier texte, un script cgi, une image...

Département Informatique
Format d’une URI

Département Informatique
Protocole HTTP : Requête (1/2)
 La requête transmise par le client au serveur comprend :
• une ligne de requête (request-line) contenant la méthode
utilisée, l’URI du service demandé, la version utilisée de
HTTP
• une ou plusieurs lignes d'en-têtes, chacune comportant un
nom et une valeur.

Département Informatique
Protocole HTTP : Requête (2/2)

 Exemple
 Le client demande le document à l'adresse
• http://www.example.com/index.html
 Accepte tous les types de document en retour
 Préfère les documents en français
 Utilise un navigateur (browser) compatible Mozilla 4.0 sur un
système Windows NT 5.1 (Windows XP)
 Signale au serveur qu'il faut garder la connexion TCP ouverte à
l'issue de la requête (car il a d'autres requêtes à transmettre).

Département Informatique
Protocole HTTP : type de méthodes (1/2)

 Lorsqu’un client se connecte à un serveur et envoie


une requête, cette requête peut prendre plusieurs
types, appelées méthodes
 Requêtes de type GET
• Pour extraire des informations
- Document, graphique
• Intègre les données de formatages de l’URI (chaîne
d’interrogation)
- www.toto.com/hello?key1=titi&key2=tata&…
 Requête de type POST
• Pour poster des informations secrètes (au sens pas
visibles dans l’en-tête), des données graphiques, …
• Transmises dans le corps de la requête

Département Informatique
Protocole HTTP : type de méthodes (2/2)

 Les méthodes

Département Informatique
Principales méthodes – GET (1/2)
 La méthode GET est une requête d’information sur une ressource
• L’information fournie en réponse l’est sous forme
- D’un ensemble d’headers

- Et d’une représentation
• Le client n’envoie jamais de représentation avec la requête (corps de la requête
vide)

Département Informatique
Principales méthodes – GET (2/2)
 La méthode GET est une requête d’information sur une ressource
• L’information fournie en réponse l’est sous forme
- D’un ensemble d’headers

- Et d’une représentation (dans le corps de la requête)

Département Informatique
Principales méthodes – DELETE

 La méthode DELETE permet de supprimer une ressource


• Tous les paramètres à transmettre au services peuvent l’être dans le
header
• Aucune donnée attendue en réponse (mais ceci est toutefois possible)

Département Informatique
Principales méthodes – POST

 La méthode POST permet de créer / ajouter une nouvelle


ressource
• Tous les paramètres à transmettre au services peuvent l’être dans le header
• Aucune donnée attendue en réponse (mais ceci est toutefois possible)

Département Informatique
Principales méthodes – PUT

 La méthode PUT permet de mettre à jour une ressource


• Inclut l’ajout d’une sous-ressource
• Tous les paramètres à transmettre au services peuvent l’être dans le header
• Aucune donnée attendue en réponse (mais ceci est toutefois possible)

Département Informatique
Principales méthodes – sureté et
idempotence

 Deux caractéristiques importantes


• La sureté
• L’idempotence
 Une méthode sûre ne doit jamais modifier l’état de la
ressource.
• Cas des méthodes GET et HEAD
• POST, DELETE et PUT ne sont pas sûres
 Une méthode est idempotente dès lors qu’elle peut être
répétée un nombre quelconque de fois, l’ensemble des
ressources reste toujours dans le même état après
l’application de la méthode
• Autrement dit, le résultat d’une opération idempotente
reste toujours le même dans un contexte donné avec des
paramètres donnés

Département Informatique
Principales méthodes – sureté et
idempotence

 La méthode GET est sure et idempotente


• Un client qui fait une requête de type GET sur une ressource ne requiert
aucun changement de cette ressource
• Le serveur peut bien sûr changer mais le client ne peut pas être tenu pour
responsable (log de la requête ou incrément d’un compteur par exemple)
• Faire un nombre quelconque de GET ou aucun devrait avoir le même
effet (ou aucun)
 Les méthodes PUT et DELETE sont idempotentes
• Faire plusieurs requêtes PUT (ou DELETE) sur une ressource doit avoir le
même effet que d’en faire une seule
• Problème connu :
- PUT qui modifie l’état de la ressource en faisant un incrément de 5 sur une valeur
- Une telle spécification n’est pas possible pour être idempotent
 La méthode POST n’est ni sure ni idempotente
• C’est elle qui sert de « boite à outils » à divers framework (messages
personnalisés, etc.)

Département Informatique
Protocole HTTP : réponse (1/3)

 La réponse transmise par le serveur au client comprend :


• Une ligne de statut contenant la version utilisée de HTTP et un code d’état
• Une ou plusieurs lignes d’en-têtes comportant un nom et une valeur
• Le corps du document retourné (les données HTML ou binaires par exemple).
- Une réponse ne contient pas obligatoirement un corps (exemple : s’il s’agit d’une réponse à
une requête HEAD, seule la ligne de statut et les en-têtes sont retournés.

Département Informatique
Protocole HTTP : réponse (2/3)

Exemple
 Le code 200 indique que le document demandé a été trouvé.
 Pour faciliter la gestion du cache du client, le serveur transmet
• la date actuelle,
• la date de dernière modification du document
• la date d'expiration (après laquelle le document doit être demandé à nouveau).

Département Informatique
Protocole HTTP : réponse (3/3)

Exemple
 L'en-tête Content-Type indique que le document retourné est de type HTML
 L'en-tête Content-Length indique que le corps du document a une longueur
de 1456 octets.
 L'en-tête Server renseigne sur le logiciel serveur utilisé.
• L’envoi d’une telle information n’est pas recommandé d’un point de vue
sécuritaire.

Département Informatique
En-têtes génériques des messages HTTP

Département Informatique
En-têtes des requêtes HTTP

Département Informatique
En-têtes des réponses HTTP

Département Informatique
Quelques codes de retour des réponses
HTTP

Département Informatique
Partie 3
Le modèle de maturité de L.
Richardson

Département Informatique
Le modèle de maturité de Richardson

 Présentation d’origine de Léonard Richardson (conférence QCON 2009)


• http://www.crummy.com/writing/speaking/2008-QCon/act3.html
 Décryptage par Martin Fowler en mars 2010
• http://martinfowler.com/articles/richardsonMaturityModel.html

Département Informatique
Le modèle de maturité de Richardson

 Le niveau 0 : Le RPC sur HTTP en POX


 Le niveau 1 : L’utilisation de ressources différenciées
 Le niveau 2 : L’utilisation des verbes et des codes retours HTTP
 Le niveau 3 : L’utilisation des contrôles hypermédia

Département Informatique
MMR – Niveau 0 – Mécanisme de «
tunneling »

 HTTP comme système de transport pour interagir à distance avec


un « service ».
• Modèle RPC/RPI (Remote Procedure Call / Invocation)
• Toutes les requêtes sont envoyées vers la même URI (ou endpoint)
• Exemple : prise de RDV chez le médecin
- Une URI unique appointmentService

Département Informatique
MMR – Niveau 0 – Mécanisme de «
tunneling »

 Exemple : prise de RDV chez le médecin


• Une URI unique appointmentService
• Le composant client doit d’abord demander au composant
serveur les horaires disponibles (open slots) à une date
donnée

Département Informatique
MMR – Niveau 0 – Mécanisme de «
tunneling »

 Exemple : prise de RDV chez le médecin


• Une URI unique appointmentService
• Le composant client doit d’abord demander au composant
serveur les horaires disponibles (open slots) à une date
donnée

Département Informatique
MMR – Niveau 0 – Mécanisme de «
tunneling »

 Exemple : prise de RDV chez le médecin


• Une URI unique appointmentService
• Puis prendre le RDV parmi les choix possibles

Département Informatique
MMR – Niveau 0 – Mécanisme de «
tunneling »

 Exemple : prise de RDV chez le médecin


• Une URI unique appointmentService
• Puis prendre le RDV parmi les choix possibles

Département Informatique
MMR – Niveau 0 – Mécanisme de «
tunneling »

 Exemple : prise de RDV chez le médecin


• Une URI unique appointmentService
• Puis prendre le RDV parmi les choix possibles

Département Informatique
MMR – Niveau 0 – Mécanisme de «
tunneling »

 HTTP comme système de transport pour interagir à distance avec un «


service ».
• Modèle RPC/RPI (Remote Procedure Call / Invocation)
 Une seule URI
 Un seule verbe HTTP utilisé (POST) qui ne distingue pas le type d’action à
exécuter coté serveur
• en outre ni sûr, ni idempotent  aucune optimisation possible
 On appelle des fonctions Approche RPC !!!!
• signatures et retour dans le corps des messages
• Ici du XML, mais tout autre format possible
 Idem SOAP ou RPC-XML – seule différence XML + grammaire spécifique

Département Informatique
MMR – Niveau 1 – L’utilisation de
ressources

 Distinction de plusieurs URIs mais toujours un seul verbe

Département Informatique
MMR – Niveau 1 – L’utilisation de
ressources

 Distinction de plusieurs URIs mais toujours un seul verbe

Département Informatique
MMR – Niveau 1 – L’utilisation de
ressources

 Distinction de plusieurs URIs mais toujours un seul verbe

Département Informatique
MMR – Niveau 1 – L’utilisation de
ressources

 Distinction de plusieurs URIs mais toujours un seul verbe

Département Informatique
MMR – Niveau 1 – L’utilisation de
ressources

 Distinction de plusieurs URIs mais toujours un seul verbe

Département Informatique
MMR – Niveau 1 – L’utilisation de
ressources

 Distinction de plusieurs URIs mais toujours un seul verbe

Département Informatique
MMR – Niveau 1 – L’utilisation de
ressources

 Distinction de plusieurs URIs mais toujours un seul verbe


 On ne fait plus ce que l’on veut du poste client Début de
découvrabilité !!
• Le serveur a la responsabilité d’indiquer la ressource pour la suite
de l’échange (http://royalhope.nhs.uk/slots/1234/ par exemple)
 Introduction de la notion d’identité d’un objet
• On n’appelle plus une fonction simplement
• On appelle une méthode sur une ressource identifié (i.e. un objet)
 Bénéfices importants
• Evite à un client de connaître l’ensemble des domaines applicatifs
du système (comme c’était le cas au niveau 0)
• La différentiation d’URIs par domaine applicatif apporte une
sémantique aux points d’entrée du système ce qui est, une des
grandes forces du style d’architecture REST.
•  prémices de l’identification de ressources

Département Informatique
MMR – Niveau 2 – Verbes et codes de
retour HTTP

 Utilisation de tous les verbes HTTP en respect de leurs spécifications


• Pour notre exemple GET et POST
• GET est sûr et idempotent pour la première requête

Département Informatique
MMR – Niveau 2 – Verbes et codes de
retour HTTP

 Utilisation de tous les verbes HTTP en respect de leurs spécifications


• Pour notre exemple GET et POST
• GET est sûr et idempotent pour la première requête

Département Informatique
MMR – Niveau 2 – Verbes et codes de
retour HTTP

 Utilisation de tous les verbes HTTP en respect de leurs spécifications


• Pour notre exemple GET et POST
• POST (comme PUT) permet la modification d’état

Département Informatique
MMR – Niveau 2 – Verbes et codes de
retour HTTP

 Utilisation de tous les verbes HTTP en respect de leurs


spécifications
• Pour notre exemple GET et POST
• POST (comme PUT) permet la modification d’état
- Dans l’en-tête : code de réponse 201+ emplacement de l’URI accessible par la
suite pour accéder à la modification début de découvrabilité encore
- Dans le corps : représentation de la ressource pour éviter un accès en consultation
sur slots/1234/appointment

Département Informatique
MMR – Niveau 2 – Verbes et codes de
retour HTTP

 Utilisation de tous les verbes HTTP en respect de leurs spécifications


• Pour notre exemple GET et POST
• POST (comme PUT) permet la modification d’état
- Changement de code de retour en cas d’erreur

Département Informatique
MMR – Niveau 2 – Verbes et codes de
retour HTTP

 Utilisation de tous les verbes HTTP en respect de leurs spécifications


• Dont PUT et DELETE qui sont peu utilisées en pratique
 Utilisation des codes de retour aux verbes HTTP
 Bénéfices importants
• l’utilisation sémantique des verbes et codes de retour HTTP enrichit le
niveau de protocole entre le client et le serveur
• Supporté par les outils (navigateurs, parefeu, routeurs, etc) en standard,
donc optimisations possibles
• L’utilisation du verbe POST permet de clairement signifier une création
de ressource de type RDV à l’aide de l’URI slots/1234/. Comme il s’agit
de la création d’un RDV (verbe POST), la partie /1234 de l’URI n’est pas
ambiguë pour le serveur : il s’agit bien entendu de l’identifiant du RDV.
• l’utilisation des codes retour HTTP permet d’apporter une sémantique
claire au client sans lire le corps du message
- 201 Created : la création a réussi
- 404 Not Found : le client en déduit que la ressource a été déplacée / supprimée

Département Informatique
MMR – Niveau 3 – Contrôles hypermédia

HATEOAS
Hypertext As The Engine Of Application State
 Au niveau 2, le client doit connaître à l’avance
• l’ensemble des URIs correspondant aux différentes
fonctionnalités du serveur
• les actions possibles sur ces URIs (les méthodes HTTP)

le client doit être au courant des requête possibles au fur et à


mesure de son chemin applicatif : il doit connaître à l’avance
les états applicatifs possibles du système.
 Au niveau 3, le client découvre pas à pas ce qu’il lui est
permis de faire au niveau de l’application et ce, grâce au
hypermédias.
• Les liens hypermédias nous guident d’état en état applicatif
sans que nous les connaissions à l’avance.

Département Informatique
MMR – Niveau 3 – Contrôles hypermédia

 HATEOAS – Hypertext As The Engine Of Application State


 Même requête initiale que pour le niveau 2

Département Informatique
MMR – Niveau 3 – Contrôles hypermédia

 Maisretour différent contenant des « hyperliens »


pour savoir où prendre les RDVs respectifs

Département Informatique
MMR – Niveau 3 – Contrôles hypermédia

 Mais retour différent contenant des « hyperliens »

Département Informatique
MMR – Niveau 3 – Contrôles hypermédia
(CH)

 Les CHs permettent au serveur de changer ses URIs sans «


casser » les clients
• Couplage faible
• Les liens ne sont plus connus en « dur » par le client mais
fournis par le serveur
 Les liens indiquent au développeur des applications clientes
les possibilités à venir (mais pas toutes les informations)
• Les contrôles "latest" et "cancel" pointent sur la même URI
(avec respectivement les verbes GET et DELETE mais ce n’est
pas spécifié par le lien)
 Pas de standard pour le moment mais des recommandations
ATOM (RCF 4287) pour définir un lien <link>
• L’attribut uri donne l’adresse de la ressource
• L’attribut rel décrit le type de relation

Département Informatique
Modèle de maturité de Léonard Richardson

 Niveau 0
• Une URI, un verbe
 Niveau 1
• Plusieurs URIs, un seul verbe
• Utilise une approche « diviser pour régner » pour casser un
unique point en plusieurs
 Niveau 2
• Plusieurs URIs, plusieurs verbes
• Introduit un ensemble standard de verbes à utiliser de manière
similaire dans des situations similaires
 Niveau 3
• Plusieurs URIs, plusieurs verbes
• Des liens entre pages
• Introduit la découvrabilité et l’auto-documentation des
protocoles d’échange

Département Informatique
Partie 4
REST et l’approche orientée
ressource

Département Informatique
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

Département Informatique
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

Département Informatique
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

Département Informatique
Etat d’une application type client – serveur
(1/2)

 Ilexiste 2 types d’états


• L’état de la ressource est l’information relative à
la ressource propre, donc au service (ex BD)
• L’état de l’application est l’information relative à
chaque client, donc liée à chaque « utilisateur ».
C’est cet état dont on veut être
indépendant

Département Informatique
Etat d’une application type client – serveur
(2/2)

Département Informatique
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

Département Informatique
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

Département Informatique
L’architecture orientée ressource repose
sur 3 concepts …

 Ressource (Identifiant)
• Identifiée par une URI
• Exemple :
http://localhost:8080/libraryrestwebservice/books
 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

Département Informatique
… 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)

Département Informatique
Ressources et URI (1/3)

 Une ressource est quelque chose qui est


identifiable dans un système
• Personne, Agenda, Document, Ensemble, Carte

 http://cours-
rest.fr/api?method=findStudent&userid=nLegoff&sessionid=06102015
 http://cours-rest.fr/students/nicolas-legoff

Département Informatique
Ressources et URI (1/3)

 Une ressource est quelque chose qui est identifiable dans un


système
• Personne, Agenda, Document, Ensemble, Carte
Mauvaise URI
 http://cours-
rest.fr/api?method=findStudent&userid=nLegoff&sessionid=06102015
Bonne URI
 http://cours-rest.fr/students/nicolas-legoff

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

Département Informatique
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

Département Informatique
Ressources et URI (3/3)

Département Informatique
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)

Département Informatique
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

Département Informatique
La représentation (2/2)

 Exemples : formats JSON et XML

Département Informatique
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)

Département Informatique
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
• www.mylibrary/2012/books/en  une représentation en anglais
• www.mylibrary/2012/books/fr  une représentation en français
 Autre solution
• www.mylibrary/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

Département Informatique
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)

Département Informatique
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.

Département Informatique
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 java.io.NotSerializableException 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??

Département Informatique
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

Département Informatique
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.

Département Informatique
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)

Département Informatique
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

Département Informatique
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é

Département Informatique
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 !!!

Département Informatique