Les services web REST

Pour D-IINFO(GL)
Par Imen Ben Lahmar
2024-2025

1
 Les types des Services web
• Deux grandes familles d’architecture orientées
services
1. WEB SOAP-based architecture
– Il est décrit en XML et standardisé par le W3C.
– Il encapsule les données échangées dans une
enveloppe qui peut-être chiffrée et contenir des
pièces jointes.
2. RESTFul architecture (Representational State
Transfer)
– REST est une "méthodologie" pour la construction
d’une application pour les services WEB.

2
 Pourquoi Rest ?
• Inconvénients de web Services SOAP:
– Les seuls messages utilisés de HTTP sont
essentiellement POST.
– architecture SOA : la mise en œuvre réelle est
complexe, les normes sont volumineuses et
difficiles à maitriser.

3
 Web Service REST
• Définition
– Acronyme de REpresentational State Transfert
défini dans la thèse de Roy Fielding en 2000.
– REST n’est pas un protocole ou un format,
contrairement à SOAP, HTTP ou RPC, mais un style
d’architecture de SOA inspiré de l’architecture du
web fortement basé sur le protocole HTTP
– REST est un ensemble de règles à respecter

4
 Principe de l’architecture REST
• Les 6 principes d'architecture REST sont :
– Client-serveur.
– Absence d'état.
– Manipulation des ressources.
– Messages auto-descriptifs
– Interface uniforme.

5
 Client/Serveur
• Deux entités :
– Client est un logiciel capable d'émettre une requête HTTP,
– un serveur qui est un API REST capable de recevoir des
requêtes HTTP pour finalement rendre une réponse HTTP.
• l’API REST fournisse un ensemble de liens au client (le
consommateur de services) pour changer l'état de l'application
• Il n'y a pas de dépendance entre les entités: chacun
peut être développé et remplacé indépendamment
tant que l'interface entre eux reste inchangée.

6
Architecture REST

7
 Absence d'état
• Les API REST sont sans état (Stateless), ce qui
signifie que le serveur ne stocke aucune
information sur les requêtes qu'il reçoit et ne
maintient pas de connexion entre les requêtes.
• De ce fait, les requêtes sont effectués
indépendamment et chaque requête est traitée
comme une première demande, sans session ni
historique.
• De plus, les appels doivent contenir toutes les
informations nécessaires au traitement des
requêtes.

8
 Manipulation des ressources
• REST est utilisée dans le développement des
applications orientés ressources (ROA) ou
orientées données (DOA)
– Une ressource est tout ce que peut désigner ou
manipuler un client, tout information pouvant être
référencée dans un lien hypertexte. Elle peut être
stockée dans une base de données.
• les états des ressources sont partagés at
accessibles par tous les clients
9
 Messages auto-descriptifs
• REST est léger et simple :
– Les messages sont courts, faciles à décoder par le
serveur d’application.
– Chaque message contient assez d'information
pour savoir comment l'interpréter.

10
 Interface unique
• Une des fonctionnalités clés d’une
architecture REST est la mise en valeur d’une
interface uniforme pour accéder à la
ressource.

• Toutes les ressources supportent les mêmes

opérations

11
 Principe REST
• Dans une architecture REST
– TOUT est ressource (archi. orientée ressource)
– Ressources identifiées par une URI (Uniform Resource
Identifier )
– Ressources manipulables via interface commune i,e.
Ressources supportent les mêmes opérations
– Chaque ressource a une représentation: XML, TEXT,
JSON, etc.
– Serveur REST: fournit un accès aux ressources
– Client REST: exploite les ressources, selon le format
voulu

12
 REST et les standards
• REST utilise les standards existants
– HTTP,
– XML, JSON, etc (formats standards d’échange entre le client et le
serveur)
• HTTP est utilisé comme protocole applicatif et non un
protocole de transport !
– HTTP offre: le transport, les méta-données, un modèle de
gestion d’erreurs, etc
– Les requêtes sont basés sur les méthodes HTTP (GET, POST,
PUT, DELETE)

13
 Gestion des ressources
• Comment identifier les ressources ?
– Utiliser des noms qui ont un sens dans la perspective d’une
interface cliente
• Comment identifier les actions ?
– Pour chaque ressource, se demander quelles sont les actions
possibles
– les principes RESTful fournissent des stratégies pour gérer les
actions CRUD à l’aide de méthodes HTTP
– Par exemple:
• GET /tickets -Récupère une liste de tickets
• GET /tickets/12 -Récupère un ticket spécifique
• POST /tickets -Crée un nouveau ticket
• PUT /tickets/12 -Met à jour le ticket #12
• DELETE /tickets/12 –Détruit le ticket #12

14
 Les méthodes
• Chaque ressource peut supporter 4 opérations de base (CRUD)
– Create
– Read
– Update
– Delete
• REST s’appuie sur le protocole HTTP pour effectuer ces opérations sur les objets
– CREATE  POST
– Read GET
– UPDATE  PUT
– DELETE  DELETE

15
 Méthode Get (1/2)
• La méthode GET retourne une représentation
de la ressource

16
 Méthode Get(2/2)
• La requête pour afficher un • La réponse: Format d’échange
livre:
HTTP/1.1 200 OK
GET/…/books/03451 Content-type: application/xml;
HTTP/1.1 charset=utf-8
Host: www… <?xml version=1.0 ?>
Accept: Nom
<books>
Application/xml
<id> 03451 </id>
Verbe <name> web service book
</name>
</books>

le client précise au serveur quel format

il désire Représentation

17
 Méthode Post (1/2)
• La méthode POST crée une nouvelle ressource
sur le système

18
 Méthode Post(2/2)

• La requête pour créer un • La réponse:

nouveau livre:
HTTP/1.1 201 Created
POST /../books/ Location: [Link]
HTTP/1.1 Content-type: application/xml;
<?xml version="1.0" ?> charset=utf-8
<books>
<id>2</id> <?xml version="1.0" ?>
<name> web service <books> [Link]
book</name> </books>
</Order>

19
 Méthode Delete (1/2)
• Supprime la ressource identifiée par l’URI sur
le serveur

20
 Méthode Delete (2/2)

• La requête pour supprimer • La réponse:

un livre:
HTTP/1.1 200 Ok
DELETE/../books/00345 Location:
HTTP/1.1 [Link]
Content-type: application/xml;
charset=utf-8
<?xml version="1.0" ?>
<books>
[Link] books/00345
</books>

21
 Méthode Put
• Mise à jour de la ressource sur le système ou
création dune nouvelle ressource.

22
 Comment ça fonctionne ?

• La requête pour modifier un • La réponse:

livre: HTTP/1.1 200 Ok
PUT /books/00346 Location:
HTTP/1.1 [Link]
<?xml version="1.0" ?> Content-type: application/xml;
<books> charset=utf-8
<id>00346</id>
<name> web service <?xml version="1.0" ?>
book</name> <books>
</books> [Link]
</books>

23
 Représentation d’une ressource
• Une représentation est fournie pour:
– le client (GET) pour désigner une format de sortie
– le serveur (PUT et POST) pour désigner un format
d’entrée et de sortie
• La représentation d’une ressource peut prendre
différents formats:
– XML
– JSON
– Text
– html
– …

24
 services web REST en Java
• JAX-RS est l’acronyme Java API for RESTful
Web Services
– Depuis la version 1.1, JAX-RS fait partie intégrante
de la spécification Java EE 6
– Seule l’approche Bottom / Up est disponible
• Le développement des services web REST
repose sur l’utilisation de classes Java et
d’annotations

25
 Les annotations de JAX-RS
• JAX-RS est basé sur les annotations
– @Path définit le chemin de la ressource. Cette
annotation se place sur la classe et la méthode
implémentant le service.
– @GET, @PUT,@POST, @DELETE définit l’action
implémentée par le service
– @Produces spécifie le type de la réponse du
service web
– @Consumes spécifie le type accepté en entré du
service web

26
 Les annotations @Path
• @Path est relative à un chemin URI. Lorsqu'elle
est utilisée sur des classes, celles-ci sont
considérées comme des ressources racine, car
elles fournissent la racine de l'arborescence des
ressources et l'accès aux sous-ressources.
• Si @Path est appliquée à la fois sur la classe et
une méthode, le chemin relatif de la ressource
produite par cette méthode est la concaténation
de la classe et de la méthode.

27
 Exemple @path

•marin/list retourne la liste des marins ;

•marin/id/15retourner le marin dont l'ID est 15
•L’URI résultante est la concaténation de l’expression du @path de la classe
avec l’expression du @path de la méthode 28
 Les annotations des opérations
• @GET  récupérer une ressource
• @POST créer une ressource
• @PUT mise à jour d’une ressource
• @DELETE  suppression d’une ressource

29
Exemple CRUD sur la ressource livre

30
 Annotations @Produces et
@Consumes
• Ces deux annotations permettent de déclarer les types MIME
supportés
– pour la requête ( @Consumes)
– et pour la réponse ( @Produces)
• On peut poser ces annotations sur une classe et/ou sur des
méthodes.
• Si l’annotation est appliqué au niveau de la classe, toutes les
méthodes acceptent les types MIME spécifiés par défaut.
• S'il est appliqué au niveau de la méthode, @Consumes/@Produces
remplace toutes les annotations appliquées au niveau de la classe.
• Si une ressource est incapable de consommer le type MIME d'une
requête client, le runtime JAX-RS renvoie une erreur HTTP 415
(“Unsupported Media Type”)

31
Exemple de @consumes et @produces
@Path("/personnels")
@Produces("application/xml’’)
@Consumes("application/xml")
public class GestionPersonnel { …}

32
 @pathParam (1/2)
• @PathParam : Cette annotation permet d'extraire la valeur du
paramètre d'une requête et de l’ajouter à une URI
• Le code suivant permet d'extraire l'identifiant du personnel 1234 de
l'URI : [Link] :
@Path("/personnels")
public class GestionPersonnel {
@GET
@Path("{idPersonnel}")
public Personne unPersonnel(@PathParam("idPersonnel") long
idPersonnel) {
return [Link]([Link], idPersonnel); }
... } 33
 @pathParam (2/2)
• Si vous avez plus d’une seule valeur à transmettre dans
l’URI l’expression doit être écrite de cette façon:
– @Path("{firstparam}-{secondparam}"
• Exemple:
@Path("/customers")
public class CustomerResource { ... @Path("{first}-{last}")
@GET @Produces("application/xml") public
StreamingOutput getCustomer(@PathParam("first")
String firstName, @PathParam("last") String lastName) {
... } }

34
 @QueryParam
• L’annotation @QueryParam est utilisée pour
extraire les valeurs des paramètres contenues
dans une requête quelque soit son type de
méthode HTTP.
• QueryParam est une annotation qui permet
de récupérer une valeur passée dans l’URL en
tant que paramètre de requête.

35
 Exemple @QueryParam

• Voici l’url:

36
 @FormParam
• L’annotation @FormParam est utilisée pour
extraire les valeurs des paramètres contenues
dans un formulaire
• Le type de contenu doit être:
application/x-www-form-urlencoded
• Cette annotation est très utile pour extraire
les informations d’une requête POST d’un
formulaire HTML

37
Exemple @FormParam

38
 Le data binding
• Lorsqu’une méthode d’une ressource retourne
une instance d’un objet Java, JAX-RS va tenter de
créer une réponse au format souhaité en fonction
de l’annotation @Produces.
• Il existe un ensemble de règles par défaut
permettant de passer d’un objet Java à un
document XML ou JSON. On appelle l’ensemble
de ces règle le data binding.
• Le data binding est assuré suite à une
sérialisation des données vers la représentation
demandée

39
 La (dé)sérialisation vers le xml

• JAXB (Java Architecture for XML Binding) permet de convertir

des objets Java en une représentation XML et vice-versa. L'API
JAXB est également fournie avec Java SE.
• L'utilisation typique de JAXB réside dans la création de beans
Java POJO (avec constructeur sans argument et
getters/setters) puis leur annotation pour définir comment les
instances de celles-ci doivent être représentées en XML. Cela
permet ainsi de communiquer des objets transformés en XML
entre des programmes Java
• Les différentes annotations utilisables sont définies dans le
paquetage [Link].

40
 Les annotations JAXB
• Voici les principales annotations appliquables sur les classes :
– @XmlRootElement(name="name",
namespace="namespace") permet d'indiquer que l'objet est
représenté sous la forme d'un élement racine XML.
• Les attributs name et namespace sont optionnels et par défaut sont
dérivés du nom de la classe et son paquetage.
– @XmlElement indique qu'un élément XML doit être utilisé pour
représenter un sous élement. Une annotation est utilisable sur
les accesseurs (getters) des propriétés d’une classe.
– @XmlAttribute indique que le champ doit être représenté sous
la forme d'un attribut
– @XmlTransient interdit la sérialisation du champ ou getter ainsi
annoté
– @XmlElementWrapper(name="name") est utilisée pour les
champs de type collection pour indiquer que toutes les valeurs
doivent être encapsulées à l'intérieur d'un élément dont le nom
à spécifierr 41
Exemple de sérialisation avec jaxb
(1/3)

42
Exemple de sérialisation avec jaxb
(2/3)

43
Exemple de sérialisation avec jaxb
(3/3)

44
 La (dé)sérialisation vers JSON

• Aujourd’hui le JSON la représentation la plus

utilisée pour plusieurs raisons :
• Jackson : bibliothèque Java spécialisée pour la
sérialisation JSON
• Vous pouvez utiliser la bibliothèque Jackson
pour déconvertir et convertir
automatiquement les objets JSON en objets
Java et vice versa

45
 La (dé)sérialisation vers JSON
• Le mapping par défaut ne requiert ni
configuration ni annotation particulière. Ce
mapping par défaut comporte des règles pour la
sérialisation/désérialisation pour les principaux
types :
– Les types primitifs
– Les dates
– Les tableaux
– Les collections
– Les énumérations
– etc

46
 Les annotations @Json
• @Jsonpropertyorder est
utilisée pour spécifier
l'ordre des propriétés
sérialisées.
• @Jsonproperty permet de
personnaliser le nom d'une
propriété et changer son
nom.
• @JsonIgnore sera utilisé
pour ignorer des attributs
lors des opérations de
sérialisation/désérialisation
• etc

47
Exemple d’annotation avec JSON

48
 Les implémentations en JAX-RS
• Différentes implémentations de la spécification JAX-RS
sont disponibles
– JERSEY : implémentation de référence fournie par Oracle
• Site projet : [Link]
– CXF : fournie par Apache, la fusion entre XFire et Celtix
• Site projet : [Link]
– RESTEasy : fournie par JBoss
• Site projet : [Link]/resteasy
– RESTlet : un des premiers framework implémentant REST
pour Java
• Site projet : [Link]
– WINK : implémentation fournie par Apache
• Site projet : [Link]

49
 Déploiement via jersey
• Déployer un service web avec Jersey (JAX-RS) peut se faire en plusieurs
étapes, en fonction de l'environnement que tu utilises (par exemple, un
serveur Tomcat, un conteneur Servlet, etc).
• Jersey a besoin d'un fichier de configuration pour déclarer les ressources que
tu veux exposer. Crée une classe AppConfig qui étend ResourceConfig pour
enregistrer les ressources.

50
 Déploiement d’un service REST

• Les applications JAX-RS sont construites et

déployées sous le format d’une application
web Java.
• La configuration de JAX-RS déclare les classes
ressources par l’intermédiaire du fichier de
déploiement ([Link])

51
Déploiement d’un service REST

52
 Client de jax-rs
1. On utilise la classe ClientBuilder pour créer une instance de la
classe Client.
2. À partir d’une instance de Client , créer un objet Target pour
préciser l’URI de la ressource visée
3. À partir d’une instance de Target , créer une requête en précisant
les types supportés par le client
4. Envoyer la requête en choisissant une méthode HTTP
– GET avec un type de retour T
– post(Entity<?> entity) : POST avec un contenu
– put(Entity<?> entity) : PUT avec un contenu
– delete(Entity<?> entity) : DELETE avec un contenu
• C’est quoi une Entity ?
– [Link](Object, MediaType) : permet de transmettre un objet en
précisant le type de média

53
 Exemple d’invocation d’une méthode
get
créer une instance
de la classe cliente

créer un objet Target

pour préciser l’URI
Préciser le chemin relatif à la de la ressource visée
ressource
Créer une requête
avec le type de
MIME supporté Créer une méthode avec le
type d’entité

54
Exemple d’invocation de la méthode
post depuis un contenu

55
Exemple d’invocation de la méthode
post à partir d’un formulaire

56
Exemple d’invocation de la méthode
put

57
 WADL
• Le WADL (Web Application Description Language)
est un format XML qui décrit l'interface d'un
service Web RESTful, de manière similaire au
WSDL pour les services Web SOAP.

• Le WADL fournit une description formelle des

ressources et des opérations accessibles par une
API REST, ainsi que des informations sur les
paramètres, les types de médias acceptés, et les
méthodes HTTP prises en charge (comme GET,
POST, PUT, DELETE, etc.).

58
 Structure de wadl
• Un fichier WADL contient une définition de service qui
inclut plusieurs éléments clés, comme :
– Les ressources : Chaque ressource (par exemple /users, /orders)
exposée par le service.
– Les méthodes HTTP : Chaque méthode associée à la ressource,
par exemple GET, POST, PUT, DELETE.
– Les paramètres : Les paramètres de la requête, tels que les
paramètres d'URL ou les paramètres de formulaire.
– Les réponses : Les types de réponses retournées par chaque
ressource (par exemple, application/json ou application/xml).

• Le fichier de description WADL est généré

automatiquement par JAX-RS (exemple :
[Link] )

59
WADL

60
 Avantages et inconvénients de WADL
• Avantages :
– Automatisation : WADL peut être généré automatiquement par
certaines implémentations de JAX-RS (comme Jersey), ce qui facilite la
documentation et l'intégration des services REST.
– Documentation : Il fournit une description formelle de l'API REST, ce
qui peut être utile pour générer de la documentation, des outils
clients, et faciliter l'interopérabilité avec d'autres systèmes.
• Inconvénients :
– Standard moins populaire : Par rapport à Swagger/OpenAPI, le WADL
est moins utilisé aujourd'hui pour la documentation des API REST.
Swagger/OpenAPI est plus répandu et offre des outils de génération
de documentation plus puissants.
– Moins d'outils disponibles : Il y a moins d'outils et de bibliothèques
disponibles pour travailler avec WADL par rapport à OpenAPI.

61
exercice
• L’objectif est de créer
un service web de
gestion des employés
dans une entreprise
• Identifier les classes à
développer et ajouter
les annotations
nécessaires sachant que
la représentation sont
sous formats xml
62
63
64
Services Web SOAP VS REST

65
 Services Web SOAP VS REST

SOAP REST
Type d’informations Exposition des Exposition des
exposées opérations ressources
Protocole de transport HTTP, autres HTTP
Description des WSDL WADL
interfaces
Format des données SOAP XML, Text, JSON…

66
 SOAP
• Avantages
– Standardisé
– Interopérabilité
– Sécurité (WS-Security)
• Inconvénients
– Performances (enveloppe SOAP supplémentaire)
– Complexité, lourdeur

67
 REST
• Avantages
– Simplicité de mise en oeuvre
– Lisibilité par un être humain
– Evolutivité
– Repose sur les principes du web
– Représentations multiples (XML, JSON,…)
• Inconvénients
– Sécurité restreinte par l’emploi des méthodes
HTTP

68
 Quand utiliser SOAP?
• Si vous estimez nécessaire d’avoir un contrat entre le
service et le client à travers une interface (WSDL)
• Si vous avez des besoins non fonctionnels (adressage,
fiabilité, sécurité, coordination,…) et que vous ne voulez pas
les coder vous-même
• Si vous avez besoin d’autres protocoles que HTTP, en
particulier sur des protocoles permettant des
communications asynchrones (SMTP, JMS,…)

69
 Quand utiliser REST ?

• Si le fournisseur et le client du service ont une

compréhension commune du contexte.

• Si vous avez besoin d’autres représentations différentes de

XML

• REST ne nécessite pas d’infrastructure particulière

70
 Bibliographie
• TUTORIEL:
– Aurélia Bruneau, « REST - Representational State Transfer », 2007
URL: [Link]
[Link]/~dr/XPOSE2007/BRUNEAU_REST/application_restful.html
– Nemanja Kojic, « REST web services », 2016
URL: [Link]
 COURS:
– Amosse EDOUARD, « COMPRENDRE L’ARCHITECTURE DES WEB
SERVICES REST », Université Nice-Sophia Antipolis, 2014
URL:
[Link]
[Link]
– Olivier Perrin, «REST », Université de Lorraine, 2014
URL: [Link]
71