Chapitre 4: Services Web
REST
Matière: SOA (Architecture Orienté Service)
Enseignante: Nourhene Ellouze
Niveau: GLSI3
Plan
1. Introduction
2. Architecture REST
3. Concepts fondamentaux de REST
4. Exemple
5. Services REST versus Services etendues
6. APIs REST
7. Outils
2
1. Introduction
3
L’utilisation du Web
1
2
2
1 2
Serveur WEB
1
1
1
2
Extraction de ressources 2
1 Serveur WEB
Ressources 2
4
L’utilisation du Web
▪ Les ressources sont récupérées au travers les URLs
▪ Une ressource (serveur) est identifiée par une URL
5
Protocole HTTP: Généralités
▪ HyperText Transfer Protocol v1.1
▪ Protocole Client/serveur sans état
▪ Impossible de conserver des informations issu du client
▪ La conversation HTTP est initialisée lorsque l’URL est saisie dans le navigateur
1- le client ouvre la connexion avec le
serveur
2 - le client émet une requête HTTP
3- le serveur répond au client
4 - la connexion est fermée
Client WEB Serveur Web
6
Protocole HTTP : requête
▪ Requête envoyée par le client (navigateur) au serveur WWW
Document Protocole
Le type de demandé. HTTP avec la
méthode de la Fichier HTML, version :
requête GET, une image... 1.0 ou 1.1
POST...
<Méthode> <URI> HTTP/<Version> La ligne
[<Champ d’en-tête>:<Valeur>]
...
blanche est
Ligne blanche obligatoire
[corps de la requête pour la méthode Post]
Différentes
informations Le corps de la requête uniquement si la
concernant le méthode est de type POST. Sont fournis
navigateur, les valeurs des paramètres envoyées par
l’utilisateur... un formulaire
7
Protocole HTTP : en-têtes de requête
▪ Correspond aux formats de documents et aux paramètres pour le serveur
▪ Accept = types MIME acceptés par le client (text/html, text/plain…)
▪ Content-Type = type MIME envoyé par le client
▪ Accept-Encoding = codage acceptées (compress, x-gzip, x-zip…)
▪ Accept-Charset = jeu de caractères préféré du client
▪ Accept-Language = liste de langues (fr, en, de…)
▪ Authorization = type d’autorisation
▪ BASIC nom:mot de passe (en base64)
▪ Transmis en clair, facile à décrypter
▪ Cookie = cookie retourné
▪ From = adresse email de l’utilisateur
8
Protocole HTTP : type de méthodes
▪ Lorsqu’un client se connecte à un serveur et envoie une requête, cette requête
peut-être de plusieurs types appelés méthodes
▪ Requête de type GET
▪ Pour extraire des informations (document, graphique…)
▪ Intègre les données de formatage à l’URL (chaîne d’interrogation)
[Link]/hello?key1=titi&key2=raoul&…
▪ Requête de type POST
▪ Pour poster des informations secrètes, des données graphiques…
▪ Transmis dans le corps de la requête
<Méthode> <URI> HTTP/<Version>
[<Champ d’en-tête>:<Valeur>]
...
Ligne blanche
[corps de la requête pour la méthode Post]
9
Protocole HTTP : réponse
▪ Réponse envoyée par le serveur WWW au client (navigateur)
Statuts des
Protocole réponses HTTP.
Liées à une erreur Donne des
HTTP avec la informations
version : ou à une réussite :
200 sur le statut :
1.0 ou 1.1 OK
HTTP/<Version><Status><Commentaire Status>
Content-Type:<Type MIME du contenu>
[<Champ d’en-tête>:<Valeur>]
... La ligne
Ligne blanche blanche est
Document obligatoire
Type de contenu qui sera
Différentes Le document peut
retourné : text/html, contenir du texte non
text/plain, application/octet- informations formaté, du code
concernant le HTML...
stream serveur...
10
Protocole HTTP : en-têtes de réponse
▪ Correspond aux informations concernant le serveur WWW
▪ Accept-Ranges = accepte ou refus d’une requête par intervalle
▪ Content-Type = type MIME envoyé par le serveur
▪ Age = ancienneté du document en secondes
▪ Server = information concernant le serveur qui retourne la réponse
▪ WWW-Authenticate = système d’authentification. Utiliser en couple avec l’en-tête
requête Authorization
▪ Location = …
11
Protocole HTTP : statuts des réponses
▪ Réponse du serveur au client <Status><Commentaire>
▪ 100-199 : Informationnel
▪ 100 : Continue (le client peut envoyer la suite de la requête)
▪ 200-299 : Succès de la requête client
▪ 200 : OK, 204 : No Content (pas de nouveau corps de réponse)
▪ 300-399 : Re-direction de la requête client
▪ 301 : Redirection, 302 : Moved Temporarily
▪ 400-499 : Erreur client
▪ 401 : Unauthorized, 404 : Not Found (ressource non trouvée)
▪ 500-599 : Erreur serveur
▪ 503 : Service Unavailable (serveur est indisponible)
▪ Le code de réponse est constitué de trois chiffres :
▪ le premier indique la classe de statut et
▪ les suivants la nature exacte de l'erreur. 12
2. Architecture REST
13
Présentation
▪ REST est l’acronyme de REpresentational State Transfert
▪ Principes définis dans la thèse de Roy FIELDING en 2000
▪ Principaux auteurs de la spécification 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
▪ REST est
▪ un style d’architecture
▪ une approche pour construire une application
▪ REST n’est pas
▪ un format
▪ un protocole
▪ Un standard
14
Présentation
▪ Les services web REST sont utilisés pour développer des architectures
orientées ressources
▪ Différentes 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 nomination REST et
RESTful
15
Les fournisseurs
▪ Principaux acteurs qui fournissent des services web REST
16
Les fournisseurs
▪ Statistiques de l’utilisation de services web REST et SOAP chez AMAZON
SOAP : 15%
REST : 85%
17
Principes de base
1. Les services web REST sont sans états (Stateless)
▪ Chaque requête envoyée par le client vers le serveur doit contenir toutes les
informations à leur traitement
▪ Le serveur ne conserve pas d'informations sur l'état de session du client entre les
requêtes
▪ Minimisation des ressources systèmes, pas de session ni d’état
2. REST repose sur la communication client-serveur
▪ le client et le serveur sont distincts et interagissent de manière indépendante via HTTP
▪ Le client envoie des requêtes HTTP au serveur, qui répond avec des réponses HTTP.
18
Principes de base
3. REST peut inclure un système de couches intermédiaires
▪ Les couches intermédiaires permettent d'améliorer la performance, la sécurité et la
gestion du trafic.
▪ Exemples de couches intermédiaires : des serveurs de cache, des passerelles ou des pare-feu.
▪ Les clients n'ont pas besoin de savoir combien de couches intermédiaires sont
impliquées dans la communication.
4. Les services web REST fournissent une interface uniforme basée sur les
méthodes HTTP (GET, POST, PUT et DELETE)
19
Principes de base
5. Manipulation des ressources
▪ Les architectures REST sont construites à partir de ressources qui sont uniquement identifiées par des URI
▪ Dans une architecture REST, les ressources sont manipulées à travers des formats de représentations
▪ Une ressource liée à un Bon de Commande est représentée par un document XML
▪ La création d’un Bon de Commande est réalisée par la combinaison d’une méthode HTTP Post et d’un document XML
▪ Dans une architecture orientée REST, la communication est obtenue par le transfert de la représentation
des ressources
▪ L’état est maintenue par la représentation d’une ressource
▪ Par conséquent, le client est responsable de l’état de la ressource
20
3. Concepts fondamentaux de
REST
21
Ressources
▪ Une ressource peut être un objet ou concept identifiable dans un système
▪ Exemples : document, image, personne, collection, service ou autre
▪ Identifié d’une manière unique par une URL (Uniform Resource Locator)
▪ Une ressource peut avoir plusieurs URI et la représentation de la ressource peut évoluer
avec le temps Identifiant primaire
de la ressource
▪ Exemple : Elle peut être représentée par une URL tel que
[Link]
Ressource de type collection
▪ Les ressources sont la base de l'API REST, et les clients interagissent avec elles en utilisant les
méthodes HTTP telles que GET, POST, PUT, et DELETE.
22
Ressources: Exemples d’URI
Ressource = 2ème livre de Harry Potter
Deux URI différentes pour
une même ressource
/books/adventures/harrypotter/2
/books/adventures/harrypotter/the_prisoner_of_azkaban
Ressource = « The Prisoner of Azkaban »
/books/adventures/harrypotter
Ressource = tous les livres d’Harry Potter
/books/adventures
Ressource = tous les livres d’aventure
23
Ressources et URI : les bonnes pratiques
▪ Privilégier l’usage des noms et non des verbes (différence avec l’approche
opération de SOAP)
/books/adventures
▪ Utiliser le pluriel pour exprimer une collection et le singulier pour la
récupération d’une seule instance
▪ /users
▪ /users/12ab
▪ Eviter l’usage de majuscule car certains serveurs ignorent les différentes types
de cases
/books/adventures/harrypotter
▪ Si plusieurs versions de l’API commencer par le numéro de version
/v3/books/adventures/harrypotter 24
États (State)
▪ Un état se réfère à l'état actuel d'une ressource à un moment donné.
▪ Chaque ressource peut avoir un état qui évolue au fil du temps.
▪ Exemple:
▪ Un compte peut avoir un état indiquant si le compte est actif ou inactif.
▪ Les clients peuvent interagir avec une ressource pour modifier ou consulter son état en
utilisant les opérations appropriées.
25
Opérations
▪ Une ressource quelconque peut subir quatre opérations de base désignées par
CRUD
▪ Create (Créer)
▪ Retrieve (Lire)
▪ Update (mettre à jour)
▪ Delete (Supprimer)
▪ REST s’appuie sur le protocole HTTP pour exprimer les opérations via les
méthodes 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 26
Opérations : Méthode GET
▪ Méthode GET fournit la représentation de la ressource
▪ Idempotente → le résultat d’une requête (à succès) est indépendant du nombre de fois
où elle a été exécutée
▪ Safe → ne modifie pas la ressource
▪ Action → récupérer
GET /books/adventures/harrypotter/2
HTTP Status: 200 (OK)
Client En-tête + Représentation Serveur
27
Opérations : Méthode POST
▪ Méthode POST crée une ressource
▪ Non idempotente → plusieurs créations de la même ressource
▪ N’est pas « Safe »
▪ Action : créer
POST /books/adventures/harrypotter/
Représentation dans le corps
HTTP Status: 201 (Created)
Client En-tête Serveur
28
Opérations : Méthode DELETE
▪ Méthode DELETE supprime une ressource
▪ Idempotente → si la ressource à supprimer n’existe pas retourner code 200 et non 204
ou 404
▪ N’est pas « Safe »
▪ Action: Supprimer
DELETE /books/adventures/harrypotter/2
HTTP Status: 200 (Ok)
Client En-tête Serveur
29
Opérations : Méthode PUT
▪ Méthode PUT met à jour une ressource
▪ Idempotente → pour s’assurer que la mise à jour s’est effectuée même en cas de panne
▪ N’est pas « Safe »
▪ Action : mise à jour
PUT /books/adventures/harrypotter/2
Représentation dans le corps
HTTP Status: 200 (Ok)
Client En-tête Serveur
30
Opérations : Méthodes→ les bonnes pratiques
▪ Utiliser les verbes appropriés pour les actions souhaitées
▪ GET = Récupérer ▪ UPDATE = Mettre à jour
▪ POST = Créer ▪ DELETE = Supprimer
▪ S’assurer qu’une méthode «Safe» ou sécurisée ne modifie pas une ressource
▪ GET est « Safe »
▪ POST, PUT et DELETE ne sont pas « Safe »
▪ S’assurer qu’une méthode «Idempotente» puisse être appelée autant de fois
avec toujours le même résultat
▪ GET, PUT et DELETE sont idempotentes
▪ POST n’est pas idempotente
31
Représentation
▪ Se réfère aux données associées à une ressource à un moment donné
Informations transférées entre le client et le serveur
▪ Fournir les données suivant une représentation pour
▪ le client (GET)
▪ le serveur (PUT et POST)
▪ Données retournées sous différents formats : XML, JSON, HTML…
▪ Une ressource peut avoir différentes représentations pour différents clients ou
pour différentes fins.
▪ Exemple : une ressource représentant un produit peut avoir une représentation détaillée
pour une page web et une autre représentation plus légère pour une application mobile
▪ Le format d’entrée (POST) et le format de sortie (GET) d’un service web d’une
ressource peuvent être différents
32
Représentation
Exemples : format JSON et XML
GET [Link]
{
"kind": "urlshortener#url",
"id": "[Link]
"longUrl": "[Link] Représentation des
"status": "OK"
}
données en JSON
GET [Link]
<?xml version="1.0"?>
<details>
Ce livre est une introduction sur la vie
</details>
Représentation des
données en XML 33
4. Exemple
34
Exemple: Hello !
▪ Principale fonctionnalité : Retour d’un message « Bonjour ! »
▪ Format XML pour la récupération des messages
35
Exemple: Hello !
▪ Requête HTTP de type GET
▪ Contenu du corps de la réponse au format XML
SOAP-UI
36
Exemple: Hello !
▪ Principale fonctionnalité : Retour d’un message « Bonjour IDS5 de la part de … ! »
▪ Format XML pour la récupération des messages
37
Exemple: Hello !
▪ Requête HTTP de type GET
▪ Contenu du corps de la réponse au format XML
SOAP-UI
38
Exemple: Hello !
▪ WADL (Web Application Description Language) en XML, utilisé pour décrire les services web
RESTful.
▪ localhost:8080/HelloRest/webresources/[Link]
39
5. Services REST versus Services
étendues
40
Services REST versus Services étendues
<soapenv:Envelope
xmlns:soapenv="[Link]
xmlns:hel="[Link]
<soapenv:Header/>
<soapenv:Body>
<hel:GetOrderDetail>
<value>14546-xx-45</value>
</hel:GetOrderDetail>
</soapenv:Body>
</soapenv:Envelope>
Client Serveur
SOAP
REST
GET [Link]
Client Serveur
41
Services REST versus Services étendues
▪ Les services web étendus (SOAP) et les services web REST différent par :
▪ Services web étendus reposent sur des standards
▪ REST est un style d’architecture
Services web étendus (SOAP) Services web REST
• Simplicité de mise en œuvre
• Standardisé
• Lisibilité par l’humain
• Interopérabilité
Avantages • Evolutivité
• Sécurité (WS-Security)
• Repose sur les principes du Web
• Outillé
• Représentations multiples
• Performances (enveloppe SOAP
• Sécurité restreinte par l’emploi des
supplémentaire)
Inconvénients méthodes HTTP
• Complexité, lourdeur
• Cible uniquement l’appel de ressource
• Cible l’appelle de service
42
6. APIs REST
43
REST: Décrire son API
▪ Pas vraiment de solution officielle pour décrire son API
▪ À l’opposé pour les services web étendus une seule solution se dégagée → WSDL
▪ Dans le monde des services web REST plusieurs solutions:
▪ OpenAPI (anciennement Swagger) → [Link]
▪ RAML → [Link]
▪ API BluePrint → [Link]
▪ WADL → [Link]/Submission/wadl
▪ Fonctionnalités proposées
▪ Décrire un service web REST quelque soit son implémentation
▪ Générer un squelette pour faciliter l’implémentation
▪ Fournir des outils pour faciliter les tests
▪ Sans vouloir choisir, OpenAPI s’est rapidement imposée par son aspect
communautaire
44
REST: Décrire son API
▪ Swagger UI : outil pour manipuler un contrat OpenAPI
▪ [Link]
Le contrat est décrit
dans un format JSON
Visualisation de
l’ensemble des
ressources et des
moyens d’y accéder
(Verbes)
45
REST: Décrire son API
▪ Swagger UI : outil pour
manipuler un contrat OpenAPI
▪ [Link]
Possibilité d’invoquer le
service pour tester
Description des
paramètres et des retours
possibles
46
REST: Décrire son API
▪ Postman : outil pour manipuler un contrat OpenAPI
47
Décrire son API : l’occasion manquée de WADL
▪ WADL (Web Application Description Langage) est un langage de description
XML de services de type REST
▪ WADL était une spécification W3C initiée par SUN
▪ [Link]/Submission/wadl/
▪ Description des services par éléments de type
▪ Ressource, Méthode, Paramètre, Requête, Réponse
▪ L’objectif était de pouvoir générer automatiquement les APIs clientes d’accès
aux services REST
▪ Remarques
▪ Peu d’outils exploitent la description WADL [Link]
▪ Apparu bien plus tard
48
Décrire son API : l’occasion manquée de WADL
▪ Exemple : afficher le WADL de services REST
<application>
<doc jersey:generatedBy="Jersey: 1.4 09/11/2010 10:30 PM"/>
<resources base="[Link]
<resource path="/contentbooks">
<resource path="uribuilder2">
<method name="POST" id="createURIBooks">
<request>
<representation mediaType="application/xml"/>
</request>
<response>
<representation mediaType="*/*"/>
</response>
</method>
</resource>
<resource path="uribuilder1">
<method name="POST" id="createBooksFromURI">
<request>
<representation mediaType="application/xml"/>
</request>
<response>
<representation mediaType="*/*"/>
</response>
</method>
</resource>
...
</resource>
</resources>
</application>
[Link] 49
7. Outils
50
Outils et bibliothèques
▪ Des outils pour appeler des services REST
▪ En ligne de commande : cURL et HTTPie
▪ Plugins Navigateur : RESTClient, Poster, RestEasy
▪ SOAPUI : [Link]
▪ Postman : [Link]
▪ Wuzz (~ Postman) : [Link]/asciimoo/wuzz
▪ SwaggerUI : [Link]/tools/swagger-ui
▪ Des plateformes pour développer (serveur) et appeler (client) des services REST
▪ JAX-RS (Jersey) pour la plateforme Java
▪ .NET
▪ PHP
▪ Python…
51
Outils et bibliothèques
▪ [Link] est un service de prévisions météorologiques orienté console qui prend en charge
diverses méthodes de représentation d'informations
▪ C:\Users\HP>curl [Link]/Tunis
52
Outils et bibliothèques
▪ [Link]
▪ [Link]
53
Outils et bibliothèques : cURL (Cheat Sheet)
▪ -H ou --header : pour passer un paramètre en en-tête
▪ -H "Content-Type: application/json"
▪ -H "Accept: application/json"
▪ -d ou --data : pour envoyer du contenu dans le payload
▪ †--data '{"id":"TR123"}'
▪ --data "@[Link]"
▪ -i : ajoute dans la réponse l’en-tête
▪ -I : montre uniquement l’en-tête de la réponse
▪ -v ou --verbose : cURL en mode « blabla »
▪ -X : pour préciser le verbe POST, GET, PUT ou DELETE
54