Table des matières

Introduction ............................................................................................................................................. 3
I. Historique ....................................................................................................................................... 4
REST ................................................................................................................................................... 4
IOT ...................................................................................................................................................... 4
SOAP .................................................................................................................................................. 4
II. PRESENTATION DES SERVICES WEB SOAP ET REST......................................................... 6
1. Qu’est-ce qu’un web service ??................................................................................................... 6
a) Définition............................................................................................................................. 6
b) L’intérêt d’un service web ................................................................................................... 6
c) Architecture d’un service web ............................................................................................. 6
d) Fonctionnements des services web ...................................................................................... 7
2- Le protocole de communication soap ............................................................................................. 9
a) Définition............................................................................................................................. 9
b) Structure d’un message SOAP .......................................................................................... 10
c) Message d’erreur SOAP .................................................................................................... 12
3. Services web REST ....................................................................................................................... 13
a) Définition........................................................................................................................... 13
b) Utilisation de la méthode HTTP ........................................................................................ 13
4. Avantages et inconvénients (protocole SOAP et service REST) .................................................. 15
III. Internet des objets ...................................................................................................................... 17
1. Défintion.................................................................................................................................... 17
 Objets connectés ................................................................................................................ 17
 Internet des objets .............................................................................................................. 17
2. Interaction entre le monde physique et le monde numérique .................................................... 17
a) Comment faire interagir ses deux mondes ........................................................................ 17
3. Les secteurs d’activités qui emploient l’IdO ............................................................................. 18
4. L’IdO et les risques pour la sécurité de l’information ............................................................... 18
5. L’IdO et la confidentialité ......................................................................................................... 19
6. L’IdO et la sécurité .................................................................................................................... 19
IV. IMPLEMENTATION ............................................................................................................... 20
1. Implémentation d’un web service SOAP .................................................................................. 20
 Création du web service .................................................................................................... 21
 Teste des méthodes du web service avec SoapUI .......................................................... 23
 Création du client SOAP................................................................................................. 23
2. Implémentation d’un web service REST ................................................................................... 25
 Création du web service REST....................................................................................... 26
Conclusion ............................................................................................................................................. 32

1
Liste des Figure
Figure 1 : Fonctionnement services web .................................................................................... 8
Figure 2 : Fonctionnement du protocole SOAP ......................................................................... 9
Figure 3 : Structure d’un message SOAP ................................................................................. 10
Figure 4 : interactions entre les deux mondes .......................................................................... 17
Figure 5 : structure du web service SOAP ............................................................................... 20
Figure 6: structure du fichier wsdl de notre web service ......................................................... 23
Figure 7: résultat de la requête consulter produit sur l'outil SoapUI ....................................... 23
Figure 8 Configuration des préférences sur SoapUI ............................................................... 24
Figure 9 : Configuration du JAX-WS Artifacts ....................................................................... 24
Figure 10:Resultat attendu par le client Soap ........................................................................... 25
Figure 11 : structure du web service REST.............................................................................. 26
Figure 12 : contenu des Library Jersey du dossier lib .............................................................. 26
Figure 13 : contenu de notre fichier web.xml .......................................................................... 27
Figure 14 : contenu de la classe BanqueRestService ............................................................... 27
Figure 15 :nouveau contenu de la classe BanqueRestService pour un web service REST...... 29
Figure 16 :résultat de la conversion en FCFA .......................................................................... 30
Figure 17 : résultat de la consultation du compte de code 5 .................................................... 30
Figure 18 : résultat de la liste des comptes au format JSON.................................................... 30
Figure 19 : modification du contenu de la classe « BanqueRestService ». .............................. 31
Figure 20 : modification du contenu de la classe « Compte» .................................................. 31
Figure 21 : résultat de la liste des comptes au format XML .................................................... 31

2
 INTRODUCTION
L’accès aux systèmes d’information s’appuie aujourd’hui de plus en plus sur des
technologies Internet. Les efforts de standardisation dans ce contexte ont accentué
l’engouement des personnes et des organisations (aussi bien académiques, qu’industrielles,
commerciales, ou institutionnelles) pour l’utilisation de l’Internet et ont permis l’émergence
des services Web comme support de développement des applications accessibles par Internet.
Ainsi, les technologies associées aux services Web sont devenues incontournables pour le
d ́développement d’applications interagissant les unes avec les autres par le biais de l’Internet.
Nous proposons dans ce chapitre de faire un point sur le sujet des services Web. L’objectif de
notre travail est de traiter des aspects conceptuels de la modélisation des services aussi bien que
des aspects liés à leur implantation

3
 I. HISTORIQUE
REST
REST est l'acronyme de "Representational State Transfer" inventé par Roy T. Fielding
dans sa dissertation "an architecture style of networked systems". Roy T. Fielding participe
depuis 1994 aux travaux du W3C sur les sujets URI, HTTP, HTML et WebDAV et a été le co-
fondateur du projet Apache, le serveur Web qui équipe 70% des sites Web de tout l'Internet (IIS
de Microsoft n'a que 20%). REST décrit les caractéristiques du Web qui en ont fait son succès.
L'explication de la signification de REST telle que donnée par Roy T. Fielding est la suivante :
"Representational State Transfer évoque l'image du fonctionnement d'une application Web bien
construite : un réseau de pages Web (une machine à états finis virtuelle) où l'utilisateur
progresse dans l'application en cliquant sur des liens (transition entre états) ce qui provoque
l'affichage de la page suivante (représentant le nouvel état de l'application) à l'utilisateur qui
peut alors l'exploiter".

IOT
L'Internet des objets est apparu dans le cadre d'une tendance lourde, issue de la mécanisation
et la standardisation, appliquée à l'automatisation du traitement du document et de l'information
sur support matériel puis numérique (dont au service de la production et recherche
documentaire). Apparu aux États-Unis dès 1982, il s'est rapidement diffusé avec la
mondialisation, aboutissant à connecter des machines à des serveurs capables de les superviser
(ces machines étant notamment des ordinateurs mis en réseau dans ce que certains ont nommé
l'« In+ternet des machines »). Peu à peu des objets ont été modifiés (avec des puces RFID par
exemple) ou conçus pour « parler le protocole IP », devenant des « objets connectés », reliés à
des serveurs centralisés ou capables de communiquer entre eux ou avec des réseaux de serveurs
et divers acteurs, d'une manière de moins en moins centralisée. Ses enjeux diffèrent selon les
pays ou les régions du monde, et selon les acteurs et « leurs intérêts parfois divergents »5. Ce
mouvement s'est accompagné d'une croissance et d'une complexification des systèmes de
sécurité (pare-feu, mots de passe, etc).

SOAP
SOAP a été conçu comme un protocole d’accès aux objets en 1998 par Dave Winer, Don
Box, Bob Atkinson et Mohsen Al-Ghosein pour Microsoft, où Atkinson et Al-Ghosein
travaillaient. Le cahier des charges n'a pas été rendu public avant d'être soumis à l'IETF le 13
septembre 1999. (Selon Don Box, cela était dû à la politique de Microsoft) En raison des
hésitations de Microsoft, Dave Winer a publié XML-RPC en 1998.

Le brouillon Internet soumis n'a pas atteint le statut RFC et n'est donc pas considéré comme un
"standard" en tant que tel. La version 1.1 de la spécification a été publiée en tant que note du
W3C le 8 mai 2000. La version 1.1 n’ayant pas atteint le statut de recommandation du W3C,
elle ne peut pas non plus être considérée comme un "standard". La version 1.2 de la
spécification, cependant, est devenue une recommandation du W3C le 24 juin 2003.

La spécification SOAP a été mise à jour par le groupe de travail sur le protocole XML du
World Wide Web Consortium jusqu'à sa fermeture, le 10 juillet 2009. SOAP était à l'origine du
mot "Simple Object Access Protocol" mais la version 1.2 de la norme l'a abandonné.

4
 Après la première introduction de SOAP, il est devenu la couche sous-jacente d’un
ensemble plus complexe de services Web, basé sur le langage WSDL (Web Services
Description Language), le schéma XML et la description et l’intégration de la description
universelle (UDDI). Ces différents services, notamment UDDI, se sont révélés beaucoup moins
intéressants, mais leur appréciation permet de comprendre parfaitement le rôle attendu de
SOAP par rapport à l'évolution réelle des services Web.

5
 II. PRESENTATION DES SERVICES WEB SOAP ET
REST
La technologie des services web est un moyen rapide de distribution de l’information entre
clients, fournisseurs, partenaires commerciaux et leurs différentes plateformes. Le services web
sont basés sur le modèle SOA (Service-Oriented Architecture).

1. Qu’est-ce qu’un web service ??

a) Définition
Un service Web est un programme informatique permettant la communication et l'échange de
données entre applications et systèmes hétérogènes dans des environnements distribués. Il s'agit
donc d'un ensemble de fonctionnalités exposées sur internet ou sur un intranet, par et pour des
applications ou machines, sans intervention humaine, et en temps réel. En d'autres termes, un
service Web est tout simplement un programme accessible au moyen d'Internet, qui utilise un
système de messagerie standard XML, et n'est lié à aucun système d'exploitation ou langage
de programmation.

b) L’intérêt d’un service web

Les services Web fournissent un lien entre applications. Ainsi, des applications utilisant des
technologies différentes peuvent envoyer et recevoir des données au travers de protocoles
compréhensibles par tout le monde.
Les services Web sont normalisés car ils utilisent les standards XML et HTTP pour transférer
des données et ils sont compatibles avec de nombreux autres environnements de
développement. Ils sont donc indépendants des plates-formes. C'est dans ce contexte qu'un
intérêt très particulier a été attribué à la conception des services Web puisqu'ils permettent aux
entreprises d'offrir des applications accessibles à distance par d'autres entreprises. Cela
s'explique par le fait que les services Web n'imposent pas de modèles de programmation
spécifiques. En d'autres termes, les services Web ne sont pas concernés par la façon dont les
messages sont produits ou consommés par des programmes. Cela permet aux vendeurs d'outils
de développement d'offrir différentes méthodes et interfaces de programmation au-dessus de
n'importe quel langage de programmation, sans être contraints par des standards comme c'est
le cas de la plate-forme CORBA qui définit des ponts spécifiques entre le langage de définition
IDl et différents langages de programmation. Ainsi, les fournisseurs d'outils de développement
peuvent facilement différencier leurs produits avec ceux de leurs concurrents en offrant
différents niveaux de sophistication.
Les services Web représentent donc la façon la plus efficace de partager des méthodes et des
fonctionnalités. De plus, ils réduisent le temps de réalisation en permettant de tirer directement
parti de services existants.

c) Architecture d’un service web

Les services Web reprennent la plupart des idées et des principes du Web (HTTP, XML), et
les appliquent à des interactions entre machines. Comme pour le World Wide Web, les services
Web communiquent via un ensemble de technologies fondamentales qui partagent une
architecture commune. Ils ont été conçus pour être réalisés sur de nombreux systèmes
développés et déployés de façon indépendante. Les technologies utilisées par les services Web
sont HTTP, WSDL, REST, XML-RPC, SOAP et UDDI.

6
REST
REST (Representational State Transfer) est une architecture de services Web. Élaborée en l'an
2000 par Roy Fiedling, l'un des créateurs du protocole HTTP, du serveur Apache HTTPd et
d'autres travaux fondamentaux, REST est une manière de construire une application pour les
systèmes distribués comme le World Wide Web.
XML-RPC
XML-RPC est un protocole simple utilisant XML pour effectuer des messages RPC. Les
requêtes sont écrites en XML et envoyées via HTTP POST. Les requêtes sont intégrées dans le
corps de la réponse HTTP. XML-RPC est indépendant de la plate-forme, ce qui lui permet de
communiquer avec diverses applications. Par exemple, un client Java peut parler de XML-RPC

à un PerlServer !
SOAP
SOAP (Simple object Access Protocol) est un protocole standard de communication. C'est
l'épine dorsale du système d'interopérabilité. SOAP est un protocole décrit en XML et
standardisé par le W3C. Il se présente comme une enveloppe pouvant être signée et pouvant
contenir des données ou des pièces jointes.
Il circule sur le protocole HTTP et permet d'effectuer des appels de méthodes à distance.
WSDL
WSDL (Web Services Description Language) est un langage de description standard. C'est
l'interface présentée aux utilisateurs. Il indique comment utiliser le service Web et comment
interagir avec lui. WSDL est basé sur XML et permet de décrire de façon précise les détails
concernant le service Web tels que les protocoles, les ports utilisés, les opérations pouvant être
effectuées, les formats des messages d'entrée et de sortie et les exceptions pouvant être
envoyées.
UDDI
UDDI (Universal Description, Discovery and Integration) est un annuaire de services. Il fournit
l'infrastructure de base pour la publication et la découverte des services Web. UDDI permet aux
fournisseurs de présenter leurs services Web aux clients.
Les informations qu'il contient peuvent être séparées en trois types :
 Les pages blanches qui incluent l'adresse, le contact et les identifiants relatifs au service
Web ;
 Les pages jaunes qui identifient les secteurs d'affaires relatifs au service Web ;
 Les pages vertes qui donnent les informations techniques.

d) Fonctionnements des services web

Le fonctionnement des services Web s'articule autour de trois acteurs principaux illustrés par le
schéma suivant :

7
 Figure 1 : Fonctionnement services web

Le fournisseur de service met en application le service Web et le rend disponible sur Internet.
Service requester programme client
C'est n'importe quel consommateur du service Web. Le demandeur utilise un service Web
existant en ouvrant une connexion réseau et en envoyant une demande en XML (REST, XML-
RPC, SOAP).
Annuaire service registry
Le registre de service est un annuaire de services. Le registre fournit un endroit central où les
programmeurs peuvent publier de nouveaux services ou en trouver. Les interactions entre ces
trois acteurs suivent plusieurs étapes :
 La publication du service : le fournisseur diffuse les descriptions de ses services Web
dans l'annuaire.
 La recherche du service : le client cherche un service particulier, il s'adresse à un
annuaire qui va lui fournir les descriptions et les URL des services demandés afin de lui
permettre de les invoquer.
 L'invocation du service : une fois que le client récupère l'URL et la description du
service, il les utilise pour l'invoquer auprès du fournisseur de services.
Description en couche des services Web
Les services Web emploient un ensemble de technologies qui ont été conçues afin de respecter
une structure en couches sans être dépendante de façon excessive de la pile des protocoles.
Cette structure est formée de quatre couches majeures :
Découverte de services UDDI
Description de services WSDL
Communication SOAP
Transport http

8
Couches technologiques des services Web.
 Le transport de messages XML-RPC ou SOAP est assuré par le standard HTTP.
 SOAP ou XML-RPC prévoit la couche de communication basée sur XML pour accéder
à des services Web.
 La description d'un service Web se fait en utilisant le langage WSDL. WSDL expose
l'interface du service.
 La publication et la découverte des services Web sont assurées par le biais du
référentiel UDDI. Un référentiel UDDI est un catalogue de services Web.

2- Le protocole de communication soap

a) Définition
SOAP (Simple Object Access Protocol) est un protocole d'invocation de méthodes sur des
services distants. Basé sur XML, SOAP a pour principal objectif d'assurer la communication
entre machines. Le protocole permet d'appeler une méthode RPC (Remote Procedure Call) et
d'envoyer des messages aux machines distantes via HTTP. Ce protocole est très bien adapté à
l'utilisation des services Web, car il permet de fournir au client une grande quantité
d'informations récupérées sur un réseau de serveurs tiers. Le schéma suivant en décrit une
illustration.

Figure 2 : Fonctionnement du protocole SOAP

D’autres de définitions normalisées de SOAP ont été proposées. Une particulièrement

intéressante définit SOAP comme étant une spécification pour une omniprésence, basée sur
XML et sur des infrastructures distribuées. De manière plus détaillés :
 Spécification car SOAP est un document qui définit le modèle de communication.
L'idée de base est que si les deux parties ont créé des programmes de mêmes
spécifications, ils seront en mesure d'interagir de façon transparente.
 Omniprésente car SOAP est défini à un niveau suffisamment élevé d'abstractions que
tout système d'exploitation et combinaison de langages de programmation peuvent être
utilisés pour créer des programmes compatibles SOAP.
 Basé sur XML, SOAP est construit sur XML, ce qui signifie que les documents SOAP
sont des documents XML construits en fonction d'un cahier de charges plus strict.

9
  Infrastructure distribuée, SOAP ne précise pas quelles données peuvent être
déplacées ou bien quels appels de fonctions peuvent avoir lieu sur elle. Les applications
construites sur la spécification SOAP peuvent déplacer les données d'un ordinateur A à
un ordinateur B et par la suite à une autre application écrite sur la même spécification.

b) Structure d’un message SOAP

La grammaire de SOAP est assez simple à comprendre. Elle procure un moyen d'accès aux
objets par appel de méthodes à distance. Les deux plus fortes fonctionnalités de SOAP sont sa
simplicité et le fait que tout le monde a accepté de l'utiliser. Un message SOAP est composé de
deux parties obligatoires : l'enveloppe SOAP et le corps SOAP ; et une partie optionnelle : l'en-
tête SOAP.

Figure 3 : Structure d’un message SOAP

SOAP envelope (enveloppe) est l'élément de base du message SOAP. L'enveloppe

contient la spécification des espaces de désignation (namespace) et du codage de
données. Elle sert de conteneur aux autres éléments du message SOAP, elle est définie
au début par la balise <soap:Envelope> et se termine par la balise </soap:Envelope>.

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding">
<soap:Header>
<!-- en-tête -->
</soap:Header>
<soap:Body>
<!-- corps -->
</soap:Body>
</soap:Envelope>

10
Les messages SOAP ne peuvent pas être envoyés en lots, autrement dit l'enveloppe contient un
seul message constitué d'un entête facultatif (SOAP header) et d'un corps obligatoire (SOAP
body).
SOAP repose entièrement sur les espaces de noms XML. Les espaces de noms sont introduits
à l'aide d'un mot-clé « xmlns » XML namespace qui signifie espace de noms XML. L'espace de
noms est utilisé pour identifier toutes les balises afin d'éviter les conflits. La spécification
impose que tous les attributs contenus dans l'enveloppe SOAP soient explicitement associés à
un namespace, de manière à supprimer toute ambiguïté. Par convention, la spécification SOAP
définit deux namespaces fréquemment utilisés :
 soap-env ou soap associé à l'URI « [..]schemas.xmlsoap.org/soap/envelope » pour
définir le namespace de l'enveloppe dans la version 1.1, et à «
[..]wwww.w3.org/2001/06/soap-envelope » dans la version 1.2 reprise par le W3C.
 soap-enc:encodingStyle associé à l'URI « [..]schemas.xmlsoap.org/soap/encoding »
pour la définition des formats de types de données dans la version 1.1, et à «
[..]www.w3.org/2001/06/soap-encoding » dans la version 1.2.

Le corps SOAP
Le corps SOAP est un élément obligatoire dans le message SOAP. Il contient l'information
destinée au receveur. Le corps (body) doit fournir le nom de la méthode invoquée par une

<soap:Body>
<checkAccountBalance>
<accountNumber xsi: type="xsd:int">1234567890</accountNumber>
</checkAccountBalance>
</soap:Body>

requête ainsi que les paramètres associés à celle-ci. Le contenu du corps SOAP est utilisé pour
spécifier un appel de méthode à un ordinateur distant avec les valeurs de paramètre. Par
exemple, la demande du solde d'un compte bancaire. L'extrait suivant représente un corps
SOAP qui fait appel de procédure distante (RPC) à une méthode appelée
checkAccountBalance().
Le corps du message SOAP commence avec la balise <soap:Body> et se termine avec la balise
</soap:Body>.
L'élément <checkAccountBalance> fournit le nom de la méthode à appeler :
checkAccountBalance. L'élément accountNumber est un paramètre qui est passé dans la
méthode checkAccountBalance.
Les attributs xsi et xsd définissent les espaces de noms qui vont être utilisés dans le corps du
message. La définition de xsi permet d'utiliser xsi:type dans le corps du message, le xsd:int
signifie que cette valeur est de type entier. 1234567890 est la valeur donnée au paramètre.

11
 L’en-tête SOAP
L'en-tête SOAP est un élément facultatif dans un message SOAP. Toutefois, si un en-tête est
présent, il doit être le premier élément qui apparaît dans l'enveloppe SOAP. Le format de l'en-
tête n'est pas défini dans le cahier des charges et par conséquent, il est à la disposition des clients
et des services pour leur propre usage. Cet usage typique serait de communiquer des
informations authentifiant l'émetteur ou bien encore le contexte d'une transaction dont le
message SOAP doit passer par plusieurs intermédiaires SOAP pour arriver au destinataire final.
Un intermédiaire SOAP est toute entité capable de recevoir et transmettre des messages SOAP.
L'en-tête d'un message SOAP commence avec la balise <soap:Header> et se termine avec la
balise </soap:Header>, je vous rappelle qu'on peut aussi faire <sopa-env:Header></sopa-
env:Header>.
Trois attributs associés à l'en-tête SOAP peuvent être utilisés :
 soap:mustUnderstand : cet attribut prend la valeur 1 ou 0. La valeur 1 signale que le
récepteur doit reconnaître l'information présente dans l'en-tête et que son traitement est
obligatoire. La valeur 0 indique que l'en-tête peut être ignoré par le récepteur.
 soap:role : sert à indiquer le destinataire SOAP auquel un bloc d'en-tête SOAP
particulier est destiné.
 soap:relay : est utilisé pour indiquer si un bloc d'en-tête SOAP ciblé sur un récepteur
SOAP doit être réacheminé (relayé) s'il n'est pas traité.
<soap:role> et <soap:relay> sont utilisés conjointement par l'ensemble des nœuds SOAP
intermédiaires qu'un message SOAP doit traverser pour arriver au destinataire final.

c) Message d’erreur SOAP

Afin de récupérer le plus grand nombre d'erreurs, l'approche SOAP se base essentiellement sur
le bon usage de la balise <soap:fault> qui est contenue dans le corps SOAP. Cette balise est
utilisée pour communiquer un problème qui a eu lieu dans la tentative de réalisation de la
demande adressée au service Web. L'élément d'erreur est facultatif et figure uniquement dans
les messages de réponse, il ne peut y apparaître qu'une seule fois. La balise <soap:fault> peut
contenir quatre autres balises facultatives :
 faultcode : cet élément est requis par le cahier des charges. Il contient un code indiquant
la nature du problème.
 faultstring : est la version lisible par l'homme de la balise faultcode. C'est la traduction
en langage naturel du code d'erreur.
 faultactor : indique le service qui a généré l'erreur. Cela est important lorsqu'une chaîne
de services a été utilisée pour traiter la demande.
 detail : cet élément doit contenir autant d'informations que possible sur l'état du serveur
à l'instant de l'apparition de l'erreur. Il contient souvent des valeurs de variables au
moment de l'échec.

12
Quatre types de codes d'erreur sont définis par la spécification :
 soap:Server : indique qu'une erreur s'est produite sur le serveur, mais pas avec le
message lui-même.
 soap:Client : signifie que le message reçu contient une erreur.
 soap:VersionMismatch : cette erreur se produit lorsque les versions des protocoles
SOAP utilisés par le client et le serveur sont différentes.
 soap:MustUnderstand : cette erreur est générée lorsqu'un élément dans l'en-tête ne
peut pas traiter alors qu'il est marqué comme obligatoire.

3. Services web REST

a) Définition
REST signifie Representational State Transfer. REST est une architecture basée sur les normes
Web et utilise le protocole HTTP. Il s'articule autour d'une ressource où chaque composant est
une ressource et où une interface commune accède à une ressource à l'aide de méthodes standard
HTTP. REST a été introduit par Roy Fielding en 2000.
Dans l'architecture REST, un serveur REST fournit simplement un accès aux ressources et le
client REST accède et modifie les ressources. Ici, chaque ressource est identifiée par des URI /
ID globaux. REST utilise diverses représentations pour représenter une ressource telle que text,
JSON, XML. JSON est le plus populaire. REST est un ensemble de règles pour créer une
application de Web Service qu'elle respecte les quatre de règles de base ci-dessous:
 Utilisation explicite de la méthode HTTP
 Apatride
 Affichage la structure de dossiers comme les URL
 Transfert JavaScript Object Notation (JSON), XML ou tous les deux.

b) Utilisation de la méthode HTTP

REST définit une règle qui oblige les programmeurs à définir clairement ses intentions par le
biais de méthode HTTP. Habituellement, l'intention qui inclut récupérée des données, insertion
de données, mise à jour de données ou effacer les données. Donc les méthodes HTTP suivantes
sont couramment utilisées dans l'architecture basée sur REST :
GET : La méthode HTTP GET est utilisée pour lire (ou récupérer) une représentation
d'une ressource. Dans le chemin sécurisé, GET renvoie une représentation au format
XML ou JSON et un code de réponse HTTP de 200 (OK). En cas d'erreur, il retourne
le plus souvent un 404 (NOT FOUND) ou un 400 (BAD REQUEST).
POST : le verbe POST est le plus souvent utilisé pour créer de nouvelles ressources. En
particulier, il est utilisé pour créer des ressources subordonnées. C’est-à-dire
subordonné à une autre ressource (par exemple mère). En cas de création réussie,
renvoie le statut HTTP 201 en renvoyant un en-tête Location avec un lien vers la
ressource nouvellement créée avec le statut http 201.

o REMARQUE : Le POST n’est ni sûr ni idempotent.

13
 PUT : Il est utilisé pour mettre à jour les capacités. Toutefois, PUT peut également
être utilisé pour créer une ressource dans le cas où l'ID de ressource est choisi par le
client plutôt que par le serveur. En d'autres termes, si le PUT est à un URI qui contient
la valeur d'un ID de ressource non existant. En cas de mise à jour réussie, retourne 200
(ou 204 si aucun contenu dans le corps n’est renvoyé) à partir d’un PUT. Si vous utilisez
PUT pour créer, renvoyez l'état HTTP 201 en cas de création réussie. PUT n’est pas sûr
mais c’est idempotent.
PATCH : Il est utilisé pour modifier les capacités. La demande PATCH doit
uniquement contenir les modifications apportées à la ressource, pas la ressource
complète. Cela ressemble à PUT, mais le corps contient un ensemble d'instructions
décrivant la manière dont une ressource résidant actuellement sur le serveur doit être
modifiée pour produire une nouvelle version. Cela signifie que le corps PATCH ne doit
pas simplement être une partie modifiée de la ressource, mais dans un type de langage
de patch tel que JSON Patch ou XML Patch. PATCH n'est ni sûr ni idempotent.
DELETE : Il est utilisé pour supprimer une ressource identifiée par un URI. Si la
suppression est réussie, renvoyez le statut HTTP 200 (OK) avec un corps de réponse.
L'exemple ci-dessous montre la façon dont utiliser GET pour ajouter plus de données sur le
serveur Utilisons GET pour demander d'ajouter un utilisateur nommé Robert.

GET /adduser?name=Robert HTTP/1.1

Utilisons GET pour demander au serveur de renommer le nom des utilisateurs

GET /updateuser?name=Robert&amp;newname=Smith HTTP/1.1

de Robert à Smith.
ET maintenant selon les règles de REST, envoyons la commande POST HTTP pour ajouter
des données :

POST /users/Robert HTTP/1.1

Host: myserver
Content-Type: application/xml
<?xml version="1.0"?>
<user>
<name>Robert</name>
</user>

14
 GET /users/Robert HTTP/1.1
Host: myserver
Accept: application/xml

Envois de la commande GET si on souhaite obtenir les données sur le système.

Envois de la commande PUT si les données souhaitent être mis à jour.

PUT /users/Robert HTTP/1.1

Host: myserver
Content-Type: application/xml
<?xml version="1.0"?>
<user>
<name>Smith</name>
</user>

Envois de la commande DELETE si les données souhaitent supprimer :

DELETE /users/Robert HTTP/1.1

4. Avantages et inconvénients (protocole SOAP et service REST)

SOAP :
 Avantages :
 Language, plate-forme, et le transport agnostique
 Conçu pour gérer les environnements informatiques distribués
 La norme est en vigueur pour les services Web, et a donc un meilleur soutien des
autres normes (WSDL, WS-*) et de l'outillage des fournisseurs
 Built-in de gestion des erreurs (fautes)
 Extensibilité
 Inconvénients :
• Conceptuellement plus difficile, plus "poids lourd" que le reste
• Un peu plus bavard
• Plus difficiles à développer, nécessite des outils
REST :

15
  Avantages :
 Language et agnostique plate-forme
 Beaucoup plus simple à développer que SOAP
 Courbe d'apprentissage Petit, moins de dépendance sur les outils
 Concise, pas besoin de couche de messagerie supplémentaire
 Closer dans la conception et la philosophie sur le Web
 Inconvénients :
 Suppose un modèle de communication point à point - non utilisable pour
l'environnement de calcul distribué dans lequel le message peut passer par un ou
plusieurs intermédiaires
 Manque de soutien pour les normes de sécurité, la politique, la messagerie fiable,
etc, afin que les services qui ont des exigences plus sophistiquées sont plus
difficiles à développer ("rouler propre")
 Lié au modèle de transport HTTP
SOAP est certainement un choix de taille pour l'accès au service Web. Il offre les avantages
suivants par rapport à REST :
 Non dépendance par rapport à la langue, la plate-forme et le transfert
(REST nécessite l'utilisation de HTTP)
 Fonctionne bien dans des environnements distribués (REST nécessite
une communication directe point à point)
 Standardisé
 Fournit une extensibilité de pré-compilation significative sous la forme
de normes WS standards
 Intègre la gestion des erreurs
 Automatisé lorsqu'il est utilisé avec des produits utilisant certains
langages de programmation
En majorité, REST est plus facile à utiliser et est plus souple. Il a les avantages suivants par
rapport à SOAP :
 Aucun besoin d'outils coûteux pour interagir avec le service Web
 Une courbe d'apprentissage plus petite pour les développeurs
 Efficace (SOAP utilise XML pour tous les messages, REST peut utiliser
des formats de message plus petits)
 Rapide (pas de traitement étendu requis)
 Proche d'autres technologies Web dans sa philosophie de conception

16
 III. INTERNET DES OBJETS

1. Défintion

 Objets connectés
Avant de définir les concepts d’IdO, il est important de définir l’objet connecté qui est un objet
possédant la capacité d’échanger des données avec d’autres entités physiques ou numériques,
sa finalité première n’est pas d’être un système informatique ni une interface d’accès au web,
exemple, un objet tel qu’une machine à café ou une serrure était conçue sans intégration de
systèmes informatiques ni connexion a internet.
L’intégration d’une connexion Internet a un OC (objets connectés) permet de l’enrichir en terme
de fonctionnalité, d’interaction avec son environnement, il devient un OC Enrichi (OCE), par
exemple, l’intégration d’une connexion internet à la machine à café la rendant accessible à
distance. Un objet connecté a une valeur lorsqu’il est connecté à d’autres objets et briques
logicielles, par exemple : une montre connectée n’a d’intérêt qu’au sein d’un écosystème orienté
santé/bien-être, qui va bien au-delà de connaître l’heure.

 Internet des objets

L’Internet des Objets est un réseau de réseaux qui permet, via des systèmes d’identification
électronique normalisés et unifiés, et des dispositifs mobiles sans fil, d’identifier directement et
sans ambiguïté des entités numériques et des objets physiques et ainsi de pouvoir récupérer,
stocker, transférer et traiter, sans discontinuité entre les mondes physiques et virtuels, les
données s’y rattachant. L’internet des objets doit être pensé pour usage facile et une
manipulation sécurisée pour éviter des risques et menaces potentiels.

2. Interaction entre le monde physique et le monde numérique

a) Comment faire interagir ses deux mondes
Pour cela, il convient de mettre en œuvre des moyens permettant à une grandeur physique de
renseigner un système informatique et, inversement, des moyens permettant à un système
informatique d’agir sur le monde physique (c’est-à-dire : changer son état).

Figure 4 : interactions entre les deux mondes

17
De manière générale, l’IoT met en œuvre deux types d’éléments pour interagir avec le monde
physique :
 les capteurs : ils permettent de recueillir des informations depuis le monde physique
et de les transmettre vers le système informatique. Par exemple, un capteur de
température permet de traduire l’amplitude de la température en une tension
électrique. Cette dernière est numérisée puis transmise.
 Les actionneurs : ils permettent au système informatique d’agir sur le monde
physique en modifiant son état. Par exemple, un actionneur peut allumer un appareil
à distance.

3. Les secteurs d’activités qui emploient l’IdO

Les applications de l’idO touchent de nos jours toute la vie quotidienne :
 la sante et les systèmes de télésurveillance pour aider les personnes.
 l’agriculture connectée pour optimiser l’usage de l’eau.
 Les véhicules connectés aident à optimiser la gestion du trafic urbain.
 Les appareils électroménagers aident à optimiser la consommation et la
distribution de l’énergie électrique.
 Les montres connectées pour le bien-être et le sport
 Etc.

4. L’IdO et les risques pour la sécurité de l’information

La mise en œuvre de l’IdO au sein d’une entreprise comporte un obstacle de taille qu’il
importe de surmonter : la sécurité. Une atteinte à la sécurité pourrait avoir d’importantes
répercussions sur la réputation et la crédibilité de l’entreprise, et se traduire par une perte de
temps et d’argent, en plus d’avoir des conséquences juridiques.
Les appareils de l’IdO se connectent entre eux, mais aussi au réseau de votre entreprise et aux
autres appareils qui utilisent celui-ci, sans oublier le fournisseur de l’IdO et les appareils de
votre personnel et de vos clients. En raison de cette inter connectivité et de cette automatisation,
un cyber incident pourrait avoir des répercussions sur les affaires de votre entreprise, depuis
son siège social jusqu’à vos clients en passant par sa chaîne d’approvisionnement.
Qu’il s’agisse d’incidents ciblant des appareils en particulier ou d’incidents indirects causés par
des menaces virales comme des logiciels malveillants, les cyber incidents peuvent avoir des
effets en aval sur la sécurité des TI de votre entreprise et affaiblir toute l’infrastructure des TI.
Par exemple, si votre entreprise possède un parc de camions de livraison pour son système de
transport intelligent et que le programmeur ou constructeur des camions est touché par un
logiciel malveillant, celui-ci pourrait aussi perturber indirectement tous vos camions connectés.
Pour de plus amples renseignements sur les logiciels malveillants.
Chaque connexion augmente le degré de vulnérabilité de votre entreprise. Il est impossible de
protéger l’information qui circule sur votre réseau si vous ne contrôlez pas l’accès des personnes
et des appareils qui s’y connectent.

18
 5. L’IdO et la confidentialité
Qu’il soit lié à l’IdO ou non, tout cyber incident augmente considérablement les risques de
vol, de divulgation ou d’altération de l’information. Ainsi, l’information concernant votre
entreprise, vos employés et vos clients pourrait être détruite, altérée, volée ou publiée, ou même
« retenue en otage » jusqu’au versement d’une rançon. Les appareils connectés collectent de
grandes quantités de données, ce qui représente un motif de préoccupation pour la
confidentialité et l’intégrité des données de l’entreprise. Assurez-vous d’utiliser des appareils
connectés qui font preuve de transparence en ce qui a trait à leurs politiques sur la collecte des
données. Ces politiques devraient préciser quelle information sera collectée, combien de temps
elle sera conservée et à quoi elle servira (à des recherches marketing, etc.)
Si vous déployez l’IdO dans votre entreprise, vous devriez mettre à jour vos politiques
concernant la confidentialité. Vous devriez envisager de recourir à une organisation
professionnelle spécialisée en cyber sécurité pour mener une étude d’impact en matière de
confidentialité, établir des normes pour l’IdO et définir des degrés de sécurité pour les rapports
entre les utilisateurs et les machines ou appareils. Par exemple, l’utilisation par un employé sûr
un appareil non sécurisé devrait être considérée comme non sécuritaire et être soumise à des
restrictions. Vous pourriez également vous adresser à un conseiller juridique pour comprendre
et réévaluer les exigences et responsabilités légales, les déclarations de confidentialité des
appareils connectés et les dispositions contractuelles. Par ailleurs, la sécurité et la confidentialité
de l’information concernant vos employés pourraient aussi être compromises par le biais des
appareils personnels connectés au réseau de l’entreprise. En informant vos employés sur l’IdO
et en leur offrant une formation sur le sujet, vous contribuerez à protéger leur vie privée.

6. L’IdO et la sécurité
Quand un appareil connecté contrôle des biens matériels et des opérations, comme un
véhicule intelligent ou une pompe à insuline, la menace que fait planer un cyber incident
éventuel ne se limite pas à une brèche dans la sécurité de l’information. L’utilisation non
autorisée ou la prise de contrôle à distance d’un objet connecté pourraient endommager les
données et l’équipement de votre entreprise ou causer des dommages physiques à des
personnes. Ces dommages pourraient s’avérer coûteux, si vous devez réparer les systèmes et
équipements de votre entreprise et rétablir sa réputation. Le rôle que jouent de nombreux objets
est bien plus important que l’information qu’ils emmagasinent. Pensez aux conséquences
juridiques et financières que pourraient entraîner la défaillance ou le piratage d’un appareil
connecté, par exemple.
Pour protéger votre équipement, votre personnel et vos clients, le cadre de sécurité de base pour
l’IdO devrait tenir compte de l’appareil, de l’aspect contrôle à distance et
L’infrastructure des TI, et comprendre :
 Démarrage sécurisé et fonctionnalité de réinitialisation
 Authentification et intégrité
 Chiffrement
 Pare-feu
 Mises à jour
 Détection d’intrusion et production de rapports
 Contrôle et vérification à distance

19
 IV. IMPLEMENTATION
Pour implémenter nos multiples web service, nous allons utiliser « Eclipse jee » pour
une implémentation JEE. Nous allons également définir un serveur local.

1. Implémentation d’un web service SOAP

Pour implémenter notre web service SOAP, le projet que nous allons effectuer consiste
à créer un service qui permet de consulter un produit et de lister tous les produits disponible
dans un magasin via le protocole SOAP.

Figure 5 : structure du web service SOAP

En effet, le but est de montrer comment pourrais s’effectuer une communication entre
un client et un magasin spécifique. On va supposer que le magasin utilisant la technologie
JavaEE (JEE) va mettre en place un script permettant de consulter le web service fournit par
le serveur Local qui peut être ici Tomcat ou un serveur que nous allons creer. L’idée ici est de
déployer le web service avec les méthodes :
 « List<Produit> listProduit()» qui va permettre de lister tous les produits
disponible dans le magasin visible au niveau du bloc « Serveur JAXWS ». Pour cela,
nous allons créer un « client http » qui devra communiquer avec le web service.
 « getProduit(Long code)» qui va permettre de consulter un produit disponible dans le
magasin.
Il est temps de se rendre sous Eclipse pour créer notre projet nommé « TPMAGASIN ».
Une fois notre projet créé, nous allons créer notre paquet « Métier » qui va contenir la classe
« produit ». Le contenue de notre classe « produit » est la suivante :
package Metier;

import java.io.Serializable;
import java.util.Date;

import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement(name="produit")
public class Produit implements Serializable{

private Long code;

private double prix_produit;
private String nom_produit;
private Date datecreation;

20
 public Long getCode() {
return code;
}
public double getPrix_produit() {
return prix_produit;
}
public void setPrix_produit(double prix_produit) {
this.prix_produit = prix_produit;
}
public String getNom_produit() {
return nom_produit;
}
public void setNom_produit(String nom_produit) {
this.nom_produit = nom_produit;
}
public Date getDatecreation() {
return datecreation;
}
public void setDatecreation(Date datecreation) {
this.datecreation = datecreation;
}
public void setCode(Long code) {
this.code = code;
}
public Produit() {
super();
}
public Produit(Long code, double prix_produit, String nom_produit,
Date datecreation) {
super();
this.code = code;
this.prix_produit = prix_produit;
this.nom_produit = nom_produit;
this.datecreation = datecreation;
}

Une fois cette classe créée, nous devons maintenant créer notre web service SOAP qui
permettra à un client http de faire une requête auprès du magasin qui est ici vue comme le
serveur Local que nous avons défini. Le principe est le suivant :
 Le client http envoie une requête au serveur pour connaitre la liste des produits
disponible;
 Le serveur fait appel à la méthode de listage définit dans la classe « BanqueService »
par l’intermédiaire du web service SOAP ;
 Ce même web service est utiliser pour transmettre le résultat de la requête au serveur
qui a son tour le transmet au client http.

 Création du web service

Pour créer notre web service, nous allons créer une classe java dans laquelle nous allons definir
toute les methodes de notre web service. Pour cela, nous allons créer notre paquet « Service »
qui va contenir la classe « MagasinService ». Le contenue de cette classe est la suivante :

21
package Service;

import java.util.ArrayList;
import java.util.Date;
import java.util.List;

import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;

import Metier.Produit;

@WebService(name="MagasinWS")
public class MagazinService {
@WebMethod
public Produit getProduit(@WebParam(name="code")Long code){
return new
Produit(code,Math.random()*200,String.valueOf(null),new Date());
}
@WebMethod
public List<Produit> listProduit(){
List<Produit> pdts=new ArrayList<>();
pdts.add(new
Produit(1L,Math.random()*200,String.valueOf(null),new Date()));
pdts.add(new
Produit(2L,Math.random()*200,String.valueOf(null),new Date()));
pdts.add(new
Produit(3L,Math.random()*200,String.valueOf(null),new Date()));
return pdts;
}
}

Une fois cela effectué, Nous allons définir notre serveur local qui va nous permettre de
tester notre web service. Pour cela, nous allons créer une classe « ServeurSoap » contenue dans
le paquet « Serveur ». Le contenu de cette classe est la suivante :
package serveur;

import javax.xml.ws.Endpoint;

import Service.MagazinService;

public class ServeurSoap {

public static void main(String[] args) {

String url="http://localhost:8585/";
Endpoint.publish(url, new MagazinService());
System.out.println(url);

Le WSDL
Il faut noter qu’on peut tester notre serveur sur un navigateur. Ce qui va nous afficher le WSDL
de notre web service. Le WSDL ici est un fichier Xml qui permet de faire la description de
l’interface du web service. Il est généré par le serveur et est fourni au client à la demande.

22
Ainsi quand un client veut faire appel à un web service, la première des choses qu’il aura besoin
c’est le WSDL. La figure si dessous nous donne un aperçu de la structure de notre web service
en format Xml :

Figure 6: structure du fichier wsdl de notre web service

 Teste des méthodes du web service avec SoapUI

Pour tester les méthodes de notre web service, nous aurons besoin d’un éditeur Xml
comme SoapUI qui est une application graphique qui permet de voir la structure des requêtes
SOAP. Pour utiliser SoapUI, vous devez créer un projet dans SoapUI et faire appel au wsdl de
notre web service en collant juste le lien d’accès que nous avons appelé dans notre navigateur
à la figure 6 vue précédemment. Nous pouvons donc voir le résultat avec SoapUI sur la figure
si dessous :

Figure 7: résultat de la requête consulter produit sur l'outil SoapUI

Une fois la vérification du bon fonctionnement des méthodes effectué, nous allons créer par la
suite un client SAOP qui devra consommer notre web service.

 Création du client SOAP

Pour créer notre client SOAP, nous allons créer un nouveau projet java dans lequel nous
allons générer un proxy qui permettra au client de consommer le web service. Notons qu’à ce
23
niveau, on ne connaît que l’adresse de notre web service. On n’est pas forcé de connaitre le
langage avec lequel notre web service a été développé pour l’exploiter.
Pour générer un proxy pour un client java, on aura besoin d’utiliser un outil qui fait
partie du JDK qui est « wsimport ». Pour cette commande wsimport, on aura juste besoin de
lui donner l’adresse du web service. Pour cela, nous devons commencer par configurer les
préférences dans SaopUI. On procède comme suite, File >> Preferences >> Tools. A ce
niveau, on aura accès à la commande wsimport du JDK en spécifiant juste le chemin d’accès
et on valide sur ok. Illustration si dessous :

Figure 8 Configuration des préférences sur SoapUI

Par la suite, nous aurons également besoin d’utiliser « JAX-WS Artifacts » qui est
disponible dans Tools de SoapUI. À ce niveau, nous n’aurons qu’à donner l’adresse du web
service, ensuite on spécifie le chemin où il va générer les classes et les mettre, on spécifie le
chemin où il va stocker les fichiers (bite code,…), enfin on valide sur « generate » pour générer
le proxy. Illustration si dessous :

Figure 9 : Configuration du JAX-WS Artifacts

Une fois cela effectué, si on revient dans notre projet ClientMagasin, on aura juste besoin
d’actualiser pour charger dans Eclipse les classes qui ont été généré hors d’Eclipse. On peut
donc constater qu’un ensemble de classe a été généré dans le dossier src de notre client.
Une fois notre proxy généré, il ne nous reste plus qu’à créer la classe ClientWS dans laquelle
nous n’aurons qu’à utiliser le proxy. Le contenu de cette classe est la suivante :
package service;

import java.util.List;

import javax.jws.WebParam;

public class ClientWS {

24
 public static void main(String[] args) {
MagasinWS stub=new MagazinServiceService().getMagasinWSPort();
Produit res=stub.getProduit(1L);
System.out.println("tecno phantom /n prix : "
+res.getPrixProduit());
System.out.println("----------------");
List<Produit> pdts=stub.listProduit();
for(Produit p:pdts){
System.out.println("tecno sparck"+p.getCode());
System.out.println("prix du tecno: "+p.getPrixProduit());
System.out.println("----------------");

}
}

Le résultat de l’exécution de cette classe permet de montrer comment le client SOAP consomme
le web service en utilisant les méthodes du web service pour transmettre et recevoir des réponses
http.

Figure 10:Resultat attendu par le client Soap

2. Implémentation d’un web service REST

Pour implémenter un projet web dynamique avec REST, nous devons tout d’abord
copier une implémentation de JAXRS. JAXRS est ici un ensemble de Library que nous devons
copier dans le dossier lib de notre projet. Dans notre cas, nous allons utiliser les fichiers Jar
« jersey » et si nous regardons dans les Library « jersey », nous trouverons également d’autre
Library tel que les fichiers Jar « jackson » qui permet de faire le mapping objet JSON. A noter
que Jersey est à la base une servlet. Hors nous savons que pour déployer une servlet dans un
projet Jee, il faut la déclarer dans le fichier web.xml.
Ainsi, la structure d’un web service REST peut se résumer sur le schéma ci-dessous :

25
 Figure 11 : structure du web service REST

On voit ici que toutes les requêtes HTTP qui sont envoyé par le client doivent passer par une
servlet qui est fourni par Jersey qui a son tour est une implémentation de JAXRS. Par contre,
ce n’est pas à nous de développer ces deux parties. Ce qui nous intéresse, c’est l’implémentation
des méthodes du web service.

 Création du web service REST

Pour commencer, rendons nous sur Eclipse pour créer notre projet web dynamique
nommé « TPREST ». Une fois que ce projet est créé, la première chose que nous allons faire
est de déployer Jersey. Pour cela, télécharger les Library qui seront visible sur la figure si
dessous, les copier et les coller dans le dossier lib de notre projet.

Figure 12 : contenu des Library Jersey du dossier lib

Par la suite, pour déployer Jersey, nous devons configurer le fichier web.xml. Pour cela, nous
devons le générer en faisant un « clic droit sur notre projet >> Java EE tools >> generate
deployment descriptor Stub ». Une fois ce fichier généré, il ne nous reste plus qu’à le
modifier.

26
 Figure 13 : contenu de notre fichier web.xml

Une fois toutes ces configurations effectuées, nous allons créer un web service qui
permet de gérer des comptes. Comme dans l’exemple du web service SOAP, cette
implémentation va également contenir une méthode de conversion de l’Euro en FCFA. En plus
de cela, nous allons définir une méthode qui permet de consulter un compte et enfin, une
méthode qui permet de liste les comptes. Pour commencer, nous allons créer une classe
« BanqueRestService » qui sera disponible dans le package « service » ; et une classe
« Compte » qui implémente l’interface serializable. Ces classes devront définir nos
différentes méthodes.
Aperçu :

Figure 14 : contenu de la classe BanqueRestService

package service;
27
import java.io.Serializable;
import java.util.Date;

public class Compte implements Serializable {

private int code;
private double solde;
private Date dateCreation;
public int getCode() {
return code;
}
public void setCode(int code) {
this.code = code;
}
public double getSolde() {
return solde;
}
public void setSolde(double solde) {
this.solde = solde;
}
public Date getDateCreation() {
return dateCreation;
}
public void setDateCreation(Date dateCreation) {
this.dateCreation = dateCreation;
}
public Compte() {
super();
// TODO Auto-generated constructor stub
}
public Compte(int code, double solde, Date dateCreation) {
super();
this.code = code;
this.solde = solde;
this.dateCreation = dateCreation;
}

}
 Quelques annotations de JAXRS
Par la suite, si nous voulons que ce soit un web service basé sur REST, nous allons
utiliser les annotations JAXRS sur notre classe « BanqueRestSercvice ». Les annotations de
JAXRS que nous allons utiliser sont :
 Utilisation de l’annotation @Path sur la classe:
 utilisation du @Path(‘’/nom_de_la_methode{parametre}’’) sur les
méthodes ;
 utilisation du @PathParam de JAXRS sur les paramètres pris par les méthodes.
 Utilisation de l’annotation @GET pour pouvoir envoyer une requête sur la méthode.

28
  Utilisation de l’annotation @Produces pour spécifier le forma que l’on va produire. Par
exemple, pour la production des données au format JSON, on va utiliser « MediaType »
de JAXRS.
 Utilisation de l’annotation @Consumes pour exiger au client d’envoyer les données
dans un autre format JSON.
En appliquant ces différentes annotations sur notre classe « BanqueRestService », on
a le contenu de la classe si dessous :

Figure 15 :nouveau contenu de la classe BanqueRestService pour un web service REST

Ainsi, toutes les données sont envoyées au format JSON. Notre web service a bien été créé. Il
ne nous reste plus qu’à tester notre web service sur le serveur Tomcat. Une fois le test effectué,
vérifions que notre projet démarre bien et sans bug sur la console de notre serveur Tomcat. Une
fois une fois cette vérification effectué, il ne nous reste plus qu’à faire des tests sur le
navigateur.
Si par exemple on souhaite convertir 60 Euro en FCFA, on tape juste sur le navigateur
http://localhost:8080/TPREST/banque/conversion/60 et on aura le résultat visible sur le
navigateur.
 TPREST représente ici le nom de notre projet ;

29
  banque représente ici le Path du web service;
 conversion représente ici la méthode que l’on souhaite appeler ;
 60 représente ici le PathParam qui est la valeur Euro que l’on souhaite convertir en
FCFA.
Une fois cette requête envoyé on obtient sur notre navigateur le résultat au format JSON si
dessous :

Figure 16 :résultat de la conversion en FCFA

Si l’on souhaite consulter un compte, on tape sur notre navigateur

http://localhost:8080/TPREST/banque/comptes/5 et on obtient le résultat si dessous :

Figure 17 : résultat de la consultation du compte de code 5

Si l’on souhaite lister tous les comptes, on tape sur notre navigateur
http://localhost:8080/TPREST/banque/comptes et on obtient le résultat si dessous :

Figure 18 : résultat de la liste des comptes au format JSON

NB : Tous ces résultats sont au format JSON.

30
Ainsi, si l’on souhaite obtenir ces résultats au format XML, on va devoir modifier l’annotation
@Produces de notre classe « BanqueRestService » ainsi que notre classe « Compte » pour
qu’elle nous fournit les résultats au format XML.
Aperçu de la modification sur la classe « BanqueRestService » :

Figure 19 : modification du contenu de la classe « BanqueRestService ».

Aperçu de la modification sur la classe « Compte » :

Figure 20 : modification du contenu de la classe « Compte»

Une fois ces modifications effectuées, en listant de nouveau les comptes, nous avons le résultat
suivant au format XML sur le navigateur :

Figure 21 : résultat de la liste des comptes au format XML

31
 CONCLUSION
Technologiquement, les Web Services sont matures pour être utilisés dans un
environnement de développement distribué. Leur promotion faite par les acteurs principaux du
marché informatique en fait une des technologies sur lesquelles il faudra compter dans le futur.
On peut notamment trouver des implémentations Web Service dans les Framework .Net
[Microsoft], WebSphere [IBM], ou WebLogic [BEA], et il existe aussi certains solutions libre
(Apache SOAP, Apache Axis ou uddi4j [IBM/HP]). Cependant, d'un point de vu innovant, les
Web Services n'apportent réellement que peu de choses par rapport aux technologies distribuées
déjà existantes telles CORBA ou JNI, les concepts novateurs introduits par les Web Services
étant pour le moment exclusivement réservés au domaine du théorique. Aussi, on est en droit
de se demander si l'apparition de cette technologie est réellement motivée par une envie
d'évolution ou bien uniquement par une stratégie marketing de la part des grand groupes
informatiques partenaires de cette technologie et coutumiers de genre ...

32