INGÉNIERIE

DES WEB
SERVICES ET
DES API
S E D D I K I LY E S
(5ÈME ANNÉE SPÉCIALITÉ RÉSEAU)
 SOMMAIRE
1. Contexte des applications distribuées

2. Les modèles d’architecture et d’exécution

3. Le modèle RPC

4. Les architectures orientées services

5. Le protocole SOAP

6. Les APIs REST

7. La sécurité des APIs

8. Les principales technologies émergentes

CATÉGORIES DE PROGRAMMES INFORMATIQUES
 PROGRAMME DISTRIBUÉ
Un programme distribué peut signifier un programme se divisant en plusieurs Threads (processus
de travail) qui peuvent travailler en parallèle.

A notre époque, et dans ce cours, cette expression désignera spécifiquement un programme

parallèle comprenant plusieurs programmes séquentiels s’exécutant sur des machines distinctes
en réseau (par opposition à différents cœurs sur une même machine)
 PROGRAMME DISTRIBUÉ
Les thèmes que recouvre "Applications distribuées": toutes les tentatives de faire participer des
machines distantes à un traitement informatique.
•système d'échange de messages,
•systèmes d'exploitation distribués
•applications réparties/parallèles

Les technologies des applications distribuées doivent s'adapter:

1. à l'évolution des technologies matérielles, marquée par évolution rapide
• des capacités des réseaux informatiques,
• des capacités des processeurs (loi de Moore puis augmentation nombre de coeurs)
2. à l'évolution des technologies logicielles, marquée par multiplication des systèmes
d'exploitation, des protocoles, ...
CLASSIFICATION DES APPLICATIONS
DISTRIBUÉES
CLASSIFICATION DES APPLICATIONS DISTRIBUÉES

Plusieurs critères peuvent permettre de classifier les systèmes et applications distribuées, parmi
ceux-ci:

1. Par leurs architectures physiques: avec principalement 2 architectures:

• Architecture Client/Serveur
• Architecture paire à paire (peer 2 peer)

2. Par le synchronisme des opérations de calcul entre applications: selon que les programme
seront coordonnés de façon directe ou avec un décalage, on a ici aussi 2 principaux modèle:
• Opérations synchrones
• Opérations asynchrones

3. Par type de parallélisme: Selon le partage de taches et de mémoire

 LES ARCHITECTURES DISTRIBUÉES
Client-serveur (organisation asymétrique)
• Le lien entre les différentes instances se fait à partir d’un serveur (physique ou virtuel), afin de
partager les informations ou les taches et de centraliser certains services.
• Modèle utilisé pour les sites Web et la plupart des applications mobiles.
• Les paires peuvent utiliser différents protocoles.
 LES ARCHITECTURES DISTRIBUÉES
Architecture paire à paire (organisation symétrique)
• Également connu par peer-to-peer, toutes les tâches sont égales, avec la logique, le contrôle et
le travail répartis uniformément entre elles. Plus précisément, chaque tâche peut communiquer
directement avec celles qui l’entourent, sans avoir à contacter un processus maître (serveur).
• Elles présentent généralement une bonne scalabilité et une tolérance de panne robuste.
• Par contre, la prise de décision est collective, ce qui implique généralement une augmentation
de la complexité de l’implémentation ainsi qu’une surcharge et une latence de communication
supérieure dans les systèmes à grande échelle.
 CALCUL SYNCHRONE ET CALCUL ASYNCHRONE
Programmation synchrone
• Appelé aussi mode bloquant, l'exécution du programme est suspendue tant que la réponse de la
requête distante n'est pas revenue ou qu'une condition d'exception n'a pas entraîné un traitement
spécifique.

Avantage: le flot de contrôle est le même que dans l'appel en mode centralisé (simule du temps réel)
Inconvénient: le client reste inactif jusqu’à la réponse du serveur
 CALCUL SYNCHRONE ET CALCUL ASYNCHRONE
Programmation asynchrone
• Le client poursuit son exécution immédiatement après l'émission du message porteur de
l'appel.
• La procédure distante s'exécute en parallèle avec la poursuite du client.
• Le client doit récupérer les résultats quand il en a besoin (primitive spéciale).

Avantage: le flot de contrôle est le même que dans l'appel en mode centralisé (simule du temps réel)
Inconvénient: le client reste inactif jusqu’à la réponse du serveur
 TYPES DE PARALLÉLISME
Quand il existe un besoin de distribuer des taches sur plusieurs nœuds réseau, on va parler de
parallélisme, un concept dans lequel soit les taches, soit les données peuvent être partagées sur les
machines.
Les 2 principaux types de parallélisme existent:
• Parallélisme des données
• Parallélisme des graphes
 TYPES DE PARALLÉLISME
Parallélisme des données
Quand les tâches sont identiques, le programme appartient à la catégorie Programme unique,
données multiples (SPMD) , comme dans l’exemple ou les mêmes données vont être partagées
sur 3 mémoires, pour le calcul d’une somme, ou on doit donc avoir un système de
synchronisation;
 TYPES DE PARALLÉLISME
Parallélisme des données
dans le cas contraire, il appartient à la catégorie Programme multiple, données multiples
(MPMD), comme dans l’exemple suivant, ou la même opération sera partagée sur 3 machines et
les données seront divisées en 3, et ensuite tous les résultats seront additionnés.
 TYPES DE PARALLÉLISME
Parallélisme des taches
Il se concentre lui sur la distribution du calcul (des taches). Une fois modélisé en tant que graphe,
un programme peut être distribué sur des machines dans un système distribué à l’aide d’une
technique de partitionnement de graphe, qui implique la division du travail (sommets) sur des
nœuds distribués afin d’optimiser le calcul distribué.
Il est largement utilisé dans de nombreux domaines tels que le machine learning, l’exploration de
données, la physique et la conception de circuits électroniques.
 TYPES D’ÉCHANGES
Indépendamment des critères vu précédemment, les programmes distribués en réseau pourront
s’envoyer des taches et des données de 2 façons principales:
Pull : cette stratégie nécessite que les destinataires d’une ressource demandent une assignation de travail.
Ce protocole réduit considérablement la complexité et peut éviter le déséquilibre de la charge, car la
décision de savoir si un destinataire particulier est prêt ou non est déléguée au subordonné lui-même. On
retrouve ce type dans les échanges http sur le Web par exemple (le client demande des ressources à un
serveur)
Push : cette stratégie attribue le travail aux subordonnés unilatéralement, sans leur demande.
L’ intérêt peut être d’obtenir des systèmes temps-réel, ou il n’y a pas besoin d’attendre des requêtes
pour y répondre, on retrouve ce type dans les technologies de sockets et de web sockets par exemple.
LES MODÈLES D’EXÉCUTION
 LES MODÈLES D’EXÉCUTION
1. Modèle RPC (client-serveur)
Le principe du Remote Procedure Call est simple, avec un appel de procédure
à distance, c’est à dire une machine qui déclenche une procédure sur une autre
(pas seulement un échange de message).

• Coté client : invoque génère l’appel distant et récupère le résultat

 Exp: invoque (id_client, id_serveur, nom_procedure, paramètres);

• Coté serveur : reçoit, traite un appel et répond

 Exp: traite (id_client, id_serveur, nom_procedure, paramètres);
 LES MODÈLES D’EXÉCUTION
1. Modèle RPC (client-serveur)
 LES MODÈLES D’EXÉCUTION
1. Modèle RPC (client-serveur)
• Modèle de Birrel et Nelson (1984)
 LES MODÈLES D’EXÉCUTION
1. Modèle RPC (client-serveur)
Langages de description d'interfaces (IDL)

Motivations:
• Spécification commune au client et au serveur contrat entre le client et le serveur
• Définition du type et de la nature des paramètres (IN, OUT, IN-OUT) ‡
• Indépendance des langages de programmation

Principes:
• Langage déclaratif
• Outils de génération des talons (stub/proxy et skeleton/squelette)
 LES MODÈLES D’EXÉCUTION
1. Modèle RPC (client-serveur)
 LES MODÈLES D’EXÉCUTION
Limites des modèles RPC

• Permet de décrire l’interaction entre deux composants logiciels

absence de vision globale de l’application

• Schéma d'exécution répartie élémentaire (appel synchrone)

• Absence de propriétés portant sur la synchronisation, la protection, la

tolérance aux pannes...

• Le RPC est un mécanisme de “bas niveau” des services additionnels sont nécessaires pour la
construction d’applications réparties (désignation, fichiers répartis, sécurité, etc.)

• Limités à la génération automatique des talons

peu (ou pas) d’outils pour le déploiement et la mise au point
d'applications réparties
 LES MODÈLES D’EXÉCUTION
2. Modèle de communication par messages

Mode ou les applications qui échangent ne sont pas définies par leur service mais par le fait qu’elles soient
émetteur ou récepteurs d’un message.

• Les communications sont la plupart du temps asynchrones

• Les émissions sont non bloquantes

• Les réceptions sont bloquantes

• L’échange entre les processus peut être direct ou indirect

 LES MODÈLES D’EXÉCUTION
2. Modèle de communication par messages
Échange direct de message:

Orienté « flux continu » (stream-oriented communications)

• Transfert d’information à forte contrainte temporelle
• Exemple : streaming audio/vidéo

Orienté « multicast »
• Données émises vers plusieurs récepteurs
• Exemples : IP multicast, multicast applicatif (sur architecture P2P), Gossip-based data dissemination
 LES MODÈLES D’EXÉCUTION
2. Modèle de communication par messages

Échange indirect de message:

• Paradigme d’interaction qui met en œuvre un système intermédiaire de propagation de messages
applicatifs entre entité émetteur (rôle de producteur) et entité récepteur (rôle de consommateur)
• Communication asynchrone
• Découplage entre producteur et consommateur
• Les rôles sont définis relativement à une interaction donnée (un nœud peut à tour de rôle être un émetteur
puis un récepteur)
• Deux modèles d’exécution :
– Message Queuing

– Publish/Subscribe
 LES MODÈLES D’EXÉCUTION
2. Modèle de communication par messages

Message queuing:

• Asynchronisme total autorisé

• Indépendance entre Producteur(s) et Consommateur(s)

• Anonymat possible des entités

• Mode « Pull » : le retrait est à l’initiative du consommateur

 LES MODÈLES D’EXÉCUTION
2. Modèle de communication par messages

Abonnements (Publish/Subscribe):
• L’émetteur envoie un message basé sur un sujet (subject-based) ou sur un contenu (content-based)
• Le récepteur s’abonne (à un sujet ou un contenu)
• Désignation anonyme
• Communication 1-N (plusieurs consommateurs peuvent s’abonner)
• Mode « Push » : le retrait est à l’initiative du producteur
 LES MODÈLES D’EXÉCUTION
3. Modèle de communication par événements

Un évènement se passant sur un des nœuds déclenchera une réaction sur un autre.

Association dynamique entre un nom d’événement et une réaction

Indépendance entre l’émetteur et les “consommateurs” d’un événement

Mode "Pull":

Les clients viennent "prendre" périodiquement leurs messages sur le serveur.

Mode "Push":  

Une méthode prédéfinie (réaction) est attachée à chaque type de message (événement) ;

l'occurrence d'un événement entraîne l'exécution de la réaction associée.

 LES MODÈLES D’EXÉCUTION
3. Modèle de communication par événements

• Beaucoup utilisé dans des domaines comme les Web Sockets, la gestion des workflows, et pour faire
coopérer des outils de développement.
 LES MODÈLES D’EXÉCUTION
4. Modèle de communication par orienté mémoire partagé

• Paradigme d’interaction proche d’un schéma Lecteur/Rédacteur sur un objet virtuellement partagé.

• Permet de programmer dans les conditions d’un système centralisé.

– utiliser une mémoire commune comme espace de communication

– synchronisation par variables partagées

• Exemples : Distributed shared memory, tuple spaces…

 LES MODÈLES D’EXÉCUTION
5. Modèle à code mobile

• Programmes pouvant se déplacer d’un nœud à l’autre, afin de rapprocher le code des données et de
réduire la taille des échanges réseau.

• Exemples : requête SQL, "applet" Java

TECHNOLOGIES PROFITANT DE LA
PROGRAMMATION DISTRIBUÉE
 TECHNOLOGIES PROFITANT DE LA
PROGRAMMATION DISTRIBUÉE

De nombreuses technologies extrêmement populaires aujourd’hui sont issue de la

programmation distribuée ou l’utilise.
 TECHNOLOGIES PROFITANT DE LA
PROGRAMMATION DISTRIBUÉE

Les APIs (Application Programming Interface)

• Elles représentent la partie d’une application exposée au monde extérieur.

• Elles permettent une séparation des rôles et du développement entre différentes machines
(comme un serveur et ses clients).

• C’est la base de conception de nombreuses autres technologies basées sur des

programmes réseau.
 TECHNOLOGIES PROFITANT DE LA
PROGRAMMATION DISTRIBUÉE

Les Web services

• Système logiciel identifié par un URI, dont les interfaces publiques et les « bindings » sont
définies et décrites en XML et exposées par un IDL nommé Web Service Description Language.

• Basés sur les architectures orientées services (SOA)

• Rassemblent un ensemble de standards ouverts, dont le plus connu est SOAP, qui permet
d’échanger en XML.
 TECHNOLOGIES PROFITANT DE LA
PROGRAMMATION DISTRIBUÉE

Les APIs REST

• APIs fonctionnant exclusivement sur HTTP, et respectant ces principes de base.

• Opérations (HTTP) : GET, PUT, POST, DELETE

• Représentation utilise le principe des « MIME types » dans l’en-tête HTTP XML
(application/xml), JSON (application-/json), ...

• Pas d’état (stateless): Chaque requête est auto-suffisante, afin de ne rien charger de superflu sur
le serveur.

• Base des principales Web APIs connues (Google Maps, Weather underground,…etc)
 TECHNOLOGIES PROFITANT DE LA
PROGRAMMATION DISTRIBUÉE

Les APIs REST

 TECHNOLOGIES PROFITANT DE LA
PROGRAMMATION DISTRIBUÉE
Les Web sockets

• L'API WebSocket est une technologie évoluée qui permet d'ouvrir un canal
de communication bidirectionnelle entre un client et un serveur, c’est un
protocole réseau basé sur TCP.

• Cette API permet d’envoyer des messages à un serveur et recevoir ses

réponses de manière événementielle sans avoir à aller consulter le serveur
pour obtenir une réponse. Ils utilisent une communication à base de Push et
peuvent être bidirectionnels.

• Le WebSocket est généralement utilisé lorsqu’une connexion rapide est

nécessaire. Par exemple: une discussion instantanée avec un service
d’assistance, un flux de nouvelles, l’affichage des données en bourse,
Messenger et aux jeux en temps réel. Avec les requêtes de connexion
habituelles, de nombreuses entreprises ont atteint leurs limites.
 TECHNOLOGIES PROFITANT DE LA
PROGRAMMATION DISTRIBUÉE

Les microservices
• Les microservices désignent à la fois une architecture et une approche de développement
logiciel qui consiste à décomposer les applications en éléments les plus simples, indépendants
les uns des autres.

• En général, chaque service prend en charge une fonctionnalité distincte, agissant comme une
mini-application dotée de sa propre logique opérationnelle.

• Pour qu'une architecture de microservices s'exécute comme une application fonctionnelle, les
services doivent en permanence demander des données à d'autres services via un système de
messagerie.

• Elles permettent une très bonne distribution des fonctionnalités, cependant, gérer un tel
environnement dynamique composé de tant de parties mobiles est une tâche complexe.
 TECHNOLOGIES PROFITANT DE LA
PROGRAMMATION DISTRIBUÉE

Les microservices
 TECHNOLOGIES PROFITANT DE LA
PROGRAMMATION DISTRIBUÉE
Le Cloud

Un cloud étant défini comme un ensemble de services logiciels, de plateforme et d’infrastructure basés sur
Internet proposés par le biais d’un cluster (ou de clusters) d’ordinateurs en réseau (par exemple, les centres de
données), il est un système distribué.

L’efficacité des programmes cloud dépend de la manière dont ils sont conçus, implémentés et exécutés. Le
processus de développement doit répondre à plusieurs considérations :

• Quel modèle de programmation sous-jacent est le plus approprié : passage de messages ou mémoire partagée ?

• L’application s’adapte-t-elle mieux à un modèle de calcul synchrone ou asynchrone ?

• Quelle est la meilleure façon de configurer les données afin d’optimiser les calculs : en utilisant le parallélisme des
données ou le parallélisme des graphes ?

• Quelle est la structure architecturale et de gestion qui améliore le plus la complexité, l’efficacité et la scalabilité des du
programmes : maître-subordonné ou pair à pair ?
 TECHNOLOGIES PROFITANT DE LA
PROGRAMMATION DISTRIBUÉE
Le Cloud

Selon la catégorie de service (IaaS, Paas, SaaS) et les besoins en terme d’applications, différents modèles
d’exécution de programmation distribuée pourront être mis en place.
 TECHNOLOGIES PROFITANT DE LA
PROGRAMMATION DISTRIBUÉE
La conteneurisation et l’orchestration

La conteneurisation est un type de virtualisation au niveau de l'application, qui permet de créer plusieurs
instances d'espace utilisateur isolées sur un même noyau.

Les conteneurs fournissent une méthode standard pour regrouper le code, le moteur d'exécution, les outils
système, les bibliothèques système et les configurations d'une application en une seule instance.

Le déploiement et l'organisation des conteneurs pour prendre en charge les applications s'appelle conteneur
orchestration, via un outil d'orchestration de conteneur. Kubernetes, Docker Swarm et LXC sont quelques-uns
des outils d’orchestration de conteneurs open source populaires.
• Ces outils doivent permettre aux conteneurs d’échanger en réseau, selon différents modes de synchronisation
et architectures.
• L’utilisation des conteneurs peut simplifier la mise en œuvre de systèmes distribués en permettant à de
multiples applications, tâches de fond et autres processus de s'exécuter de façon autonome à travers plusieurs
machines isolées.
 TECHNOLOGIES PROFITANT DE LA
PROGRAMMATION DISTRIBUÉE
La Blockchain:

Technologie de stockage et de transmission d’informations, transparente, sécurisée, et fonctionnant sans

organe central de contrôle.

Par extension, une blockchain constitue une base de données distribuée qui contient l’historique de tous les
échanges effectués entre ses utilisateurs depuis sa création. Elle est partagée par ses différents utilisateurs, sans
intermédiaire, ce qui permet à chacun de vérifier la validité de la chaîne.
 TECHNOLOGIES PROFITANT DE LA
PROGRAMMATION DISTRIBUÉE
Le cloud native:

Concept d’applications évolutives sur des environnements dynamiques et en réseau. Elles sont conçues pour
s’étendre horizontalement plutôt que verticalement et se basent sur des technologies comme les conteneurs, les
microservices et les API.
LES ARCHITECTURES DISTRIBUÉES

Client-serveur (2-tiers)
• Rôles spécifiques
• Caractéristiques distinctes
• Les paires peuvent utiliser différents protocoles
LES ARCHITECTURES DISTRIBUÉES
3-tiers ou N-tiers
Une infrastructure physique qui va servir de support à une infrastructure
logicielle (l'infrastructure trois tiers sous-tend l'infrastructure logicielle).En
effet, n'importe quelle application peut-être découpée en trois parties : une
partie interface graphique, une partie fonctionnelle, et une partie de stockage
de données.
LES ARCHITECTURES DISTRIBUÉES
Dans un contexte comme celui des sites internet classiques, le serveur génère
le contenu pour les client (éventuellement à partir de BDD)…

Mais quand des applications indépendantes ont besoin

de données ou de services externes pour fonctionner ?

Besoin d’avoir des applications distribuées

(s’exécutant sur plusieurs machines) ou de
pouvoir faire des appels distants vers d’autres
applications
OBJECTIFS
Ces applications ont 3 objectifs principaux selon Microsoft:

• Pouvoir industrialiser l’échanges d’informations,

• Sécuriser et contrôler les échanges de données :
savoir qui ? comment ? cb de fois ? les personnes
accèdent à l’API et donc…
• pouvoir optimiser et développer les usages
multidisciplinaires
• Quelles technologies pour créer ces
applications ?
 LES SOCKETS

• Les sockets servent à communiquer entre deux hôtes appelés Client /

Serveur à l'aide d'une adresse IP et d'un port.
• Couche transport du modèle OSI
• Soit en mode connecté (protocole TCP)
• Ou en mode non connecté (par UDP)
• Echange de messages ou de fichiers sur commande
CONNEXION ENTRE 2 SOCKETS

• Une fois créé le socket qui reçoit des demandes de communication, peut
être appelé par un autre socket
• Il faut connecter un socket à un autre socket qui est en attente
(connect)

• Une fois la connexion établie, la conversation peut commencer (read,

write…)

• À la fin de la communication (comme on raccroche le téléphone) il faut

fermer le socket qui a servi à la communication (close)

Inttic Les sockets

53
WEB SOCKETS

54
WEB SOCKETS

55
RPC (REMOTE PROCEDURE CALL)
– Avantages de la communication en appel de procédure
distante:
• Ne pas avoir à programmer des échanges au niveau réseau en mode message.

• Utiliser une structure familière (l’appel de procédure)

• Vision modulaire des applications réparties.

• Réutilisation par délégation en univers réparti.

RPC (REMOTE PROCEDURE CALL)

• Le principe le plus simple, avec un appel de procédure à distance, c’est à dire une machine qui
déclenche une procédure sur une autre (pas seulement un échange de message).
• /* Coté client : invoque génère l’appel distant et récupère le résultat
 Exp: invoque (id_client, id_serveur, nom_procedure, paramètres);
• /* Coté serveur : reçoit, traite un appel et répond
 Exp: traite (id_client, id_serveur, nom_procedure, paramètres);
RPC (REMOTE PROCEDURE CALL)
• Souches client et serveur

La souche client (“client stub”)

• Procédure coté client qui reçoit l’appel en mode local
• Le transforme en appel distant
• En envoyant un message
• Reçoit le message contenant les résultats après l'exécution
• Retourne les résultats comme dans un retour de procédure.

La souche serveur (“server stub”)

• Procédure coté serveur qui reçoit le message d ’appel,
• Fait réaliser l’exécution sur le site serveur par la procédure serveur
• Récupère les résultats et retransmet les résultats par message.
RPC (REMOTE PROCEDURE CALL)
RPC (REMOTE PROCEDURE CALL)
Appel de procédure distante en mode synchrone
• L'exécution du client est suspendue tant que la réponse du serveur n'est pas revenue ou
qu'une condition d'exception n'a pas entraîné un traitement spécifique.

Avantage: le flot de contrôle est le même que dans l'appel en mode centralisé
(simule du temps réel)
Inconvénient: le client reste inactif jusqu’à la réponse du serveur
RPC (REMOTE PROCEDURE CALL)
Appel de procédure distante en mode asynchrone
• Le client poursuit son exécution immédiatement après l'émission du message porteur
de l'appel.
• La procédure distante s'exécute en parallèle avec la poursuite du client.
• Le client doit récupérer les résultats quand il en a besoin (primitive spéciale).
RPC (REMOTE PROCEDURE CALL)
IDL (Interface Définition Language )
Une syntaxe de transfert qui permet au client et au serveur de se comprendre
Permettre l’invocation distante avec tout langage évolué
• Définition d’un langage pivot de description de données ayant des fonctionnalités
assez riches pour les langages les plus récents.
• Définition d ’un langage pivot qui permette de corriger les ambiguïtés et les
insuffisances des langages anciens (comme par exemple C).
• Notion de correspondance entre les types retenus dans l'IDL et les types des différents
langages existants ("mappings")

• Ces langages sont souvent représenter dans des formats standards, en particulier
XML et JSON
EN QUEL FORMAT COMMUNIQUER
Les services Web échangent des données dans des formats qui doivent être interprétables
par tous les serveurs et tous les types de clients pouvant échanger.
• Text/plain: Format string basique, pour les échanges de messages simples
• XML: Un langage standardisé par la W3C et basé sur un système de balises. Il peut
décrire à la fois des valeurs et les relations entre les valeurs
• JSON: C’est la syntaxe de base des objets du langage JavaScript. C’est une
représentation sans schéma, en texte clair, de données structurées basées sur des paires
nom/valeur et des listes ordonnées, et on peut y stocker toute sorte de données (string,
nombres, arrays, fonctions…etc)

Des fichiers peuvent également être transmis, souvent à travers les types définis par le
standard MIME (Multipurpose Internet Mail Extensions) qui contient de nombreux
types de médias à transmettre (image, audio, video…etc)
LES SERVICES WEB

• Un service web est un système logiciel identifié par un URI, dont les
interfaces publiques et les « bindings » sont définies et décrites en XML.
• Le principe est basé sur les Architectures orientées services (SOA)
• Sa définition peut être découverte [dynamiquement] par d’autres systèmes
logiciels. Ces autres systèmes peuvent ensuite interagir avec le service web
d’une façon décrite par sa définition, en utilisant des messages XML
transportés par des protocoles Internet.

Extension de XML-RPC
LES SERVICES WEB
LES SERVICES WEB
Groupe de standards ouverts

• Pour standardiser la communication entre composants distribués (réseau)

• Principalement basé sur XML
• Utilise généralement HTTP
• Regroupe plusieurs entreprises : Microsoft, IBM, Sun et Oracle, HP…
• Regroupe et utilise plusieurs standards (XML, HTTP….)
• La définition de « web service » peut varier, parfois pour définir tous les servives
accessible à distance selon un IDL, et parfois seulement ceux basés sur XML…

Le premier grand standard fut SOAP (Simple Object Access Protocol)

QU’EST CE QUE LES API

• L’API, pour Application Programming Interface, est la partie du programme qu’on expose
officiellement au monde extérieur pour manipuler celui-ci. L’API est au développeur ce que
l’User Interface est à l’utilisateur. Cette dernière permet d’entrer des données et de les récupérer
la sortie d’un traitement. Initialement, une API regroupe un ensemble de fonctions ou méthodes,
leurs signatures et ordre d’usage pour obtenir un résultat.
• La mise en place d’une API permet d’opérer une séparation des responsabilités entre le client et
le serveur. Cette séparation permet donc une portabilité et évolutivité grandement améliorées.
Chaque composant peut évoluer séparément car il n’y a aucune logique du côté du serveur.
• Ainsi on peut imaginer une refonte totale de la charte graphique du site web sans devoir
modifier le code côté serveur ou sur les autres clients.
• Le protocole SOAP
 SOAP
Principes
• Protocole d’échanges d’informations dans un environnement distribué basé sur XML
• Interopérabilité entre applications d’une même entreprise (Intranet)
• Interopérabilité inter entreprises entre applications et services web
• SOAP peut utilisé plusieurs protocoles : HTTP, SMTP, POP
 SOAP
SOAP est principalement composé de trois parties:
• Les enveloppes SOAP (ou Message)
• Les règles d’encodages
• La représentation RPC
 SOAP
L’Enveloppe SOAP est Obligatoire , elle possède:
• Une en-tête (Header) Optionnelle
• Le corps (Body) qui est Obligatoire

• Balise optionnelle identifié par <namespace:Header>

• Quand il est présent, il doit être avant le Body
• Utilisé pour transmettre des informations supplémentaires entre le
consommateur et le fournisseur du service
• Usages possibles:
 Informations d’authentification
 Contexte d’une transaction
 Transiter des informations intermédiaires
 SOAP
En-tête
• Balise optionnelle identifié par <namespace:Header>
• Quand il est présent, il doit être avant le Body
• Utilisé pour transmettre des informations supplémentaires entre le consommateur
et le fournisseur du service
• Usages possibles:
 Informations d’authentification
 Contexte d’une transaction
 Transiter des informations intermédiaires

Corps
• Identifié par la balise <namespace:Body>
• Contient la réponse à l’appel d’une action du service
 Une erreur
 Réponse de l’action
 SOAP
WSDL (Web Service Description Language )

• Est l’IDL utilisé par SOAP

• Sert à l’encodage du Body
• Fichier au format XML
• Décrit les actions exposées par le web service
 SOAP

UDDI (Universal Description Discovery and Integration)

• Est une sorte d’annuaires pour un groupe de services Web
• Dépôt/Registre (repository/registry)
• Permet d’enregistrer des services
• Permet de découvrir des services
• But : Ne pas avoir à écrire en dur (hardcoder) l’adresse d’un service
SOAP
 SOAP

Même si SOAP reste utilisé dans beaucoup d’entreprise, le groupe

chargé de sa spécification n’a plus émis de màj depuis 2009, et un
autre standard l’a largement supplanter ces dernières années… le
REST (Representational State Transfer)
• L’architecture REST
 LES ARCHITECTURES REST ET SOAP

• Les deux techniques ont des problèmes à prendre en compte au moment de décider quel
protocole utiliser. Avant d'aller plus loin, il est important de préciser que même si SOAP et
REST présentent des similitudes en utilisant le protocole HTTP, SOAP est un ensemble plus
rigide que REST. REST a une architecture qui ne nécessite pas de traitement et qui est
naturellement plus flexible. SOAP et REST reposent sur des règles bien établies que tout le
monde a accepté de respecter dans l'intérêt de l'échange d'informations.
 L’ARCHITECTURE REST

• Identification : URIs
• Opérations (HTTP) : GET, PUT, POST, DELETE
• Contenu
– Représentation
– Utilise le principe des « MIME types » dans l’en-tête HTTP XML (application/xml), JSON (application-/json), ...
• Pas d’état (stateless): Chaque requête est auto-suffisante, afin de ne rien charger de superflu sur le serveur.
• Orienté ressources
– Représentation = état courant de la ressource
– Liens entre les ressources par hyperliens (href)
 L’ARCHITECTURE REST

• Exemple
 L’ARCHITECTURE REST
• Une API REST se doit d’être sans état ou stateless en anglais. La
communication entre le client et le serveur ne doit pas dépendre d’un
quelconque contexte provenant du serveur. Ainsi, chaque requête doit
contenir l’ensemble des informations nécessaires à son traitement. Cela
permet au serveur de traiter indifféremment les requêtes de plusieurs clients
via de multiples instances de serveurs.

Roy
Fielding
(2000)
 L’ARCHITECTURE REST
Critères du Rest
• Il existe quatre grands niveaux d’évaluation d’une API. Au plus on atteint un niveau élevé au
plus notre API est considérée comme RESTful et respecte ce qu’on appelle communément les
“bonnes pratiques”.
• Client–serveur
• Sans état (stateless)
• Avec mise en cache
• En couches (impossible de déterminer le nombre de saut)
• Avec code à la demande
• Interface uniforme
– Identification des ressources dans les requêtes
– Manipulation des ressources par des représentations
– Messages auto-descriptifs
– Hypermédia comme moteur d'état de l'application
 L’ARCHITECTURE REST
Caractéristiques :
• Les services REST sont sans états (Stateless)
– Chaque requête envoyée au serveur doit contenir toutes les informations relatives à son
état et est traitée indépendamment de toutes autres requêtes
– Minimisation des ressources systèmes (pas de gestion de session, ni d’état)

• Interface uniforme basée sur les méthodes HTTP (GET, POST, PUT,
DELETE)
• Les architectures RESTful sont construites à partir de ressources
uniquement identifiées par des URI(s)
 L’ARCHITECTURE REST
Structure d’une requête :
• Ressources : Identifiée par une URI
Exp: ( http://unice.fr/cursus/master/miage)

• Méthodes (verbes) permettant de manipuler les ressources (Méthodes HTTP

: GET, POST, PUT, DELETE )

• Représentation : Vue sur l’état de la ressource, Format d’échanges entre le

client et le serveur (XML, JSON, text/plain,…)
L’ARCHITECTURE REST
 L’ARCHITECTURE REST
Les codes status les plus courants que l’on retrouve généralement sur le web sont :
200 OK Tout s'est bien passé
201 Created La création de la ressource s'est bien passée (il n’est pas rare que les attributs de la
nouvelle ressource soient aussi renvoyées dans la réponse. Dans ce cas, l’URL de cette ressource
nouvellement créée est ajouté via un header Location )
• 204 No content Même principe que pour la 201, sauf que cette fois-ci, le contenu de la ressource
nouvellement créée ou modifiée n'est pas renvoyée en réponse
• 304 Not modified Le contenu n'a pas été modifié depuis la dernière fois qu'elle a été mise en cache
• 400 Bad request La demande n'a pas pu être traitée correctement
• 401 Unauthorized L'authentification a échoué
• 403 Forbidden L'accès à cette ressource n'est pas autorisé
• 404 Not found La ressource n'existe pas
• 405 Method not allowed La méthode HTTP utilisée n'est pas traitable par l'API
• 406 Not acceptable L’API est dans l’incapacité de fournir le format demandé par les en têtes
Accept. Par exemple, le client demande un format (XML par exemple) et l'API n'est pas prévue
pour générer du XML
• 500 Server error Le serveur a rencontré un problème.
L’ARCHITECTURE REST
 L’ARCHITECTURE REST
Plusieurs technologies de requêtage synchrone/asynchrone client peuvent être utilisés en
JavaScript:

• XMLHttpRequest
• Ajax
• Fetch API
• Axios
• La gestion des accès et la sécurité
CROSS-ORIGIN RESOURCE SHARING 
(CORS) 
• Mécanisme qui consiste à ajouter des en-têtes HTTP afin de permettre à un
agent utilisateur d'accéder à des ressources d'un serveur situé sur une autre
origine que le site courant. Un agent utilisateur réalise une requête
HTTP multi-origine (cross-origin) lorsqu'il demande une ressource
provenant d'un domaine, d'un protocole ou d'un port différent de ceux
utilisés pour la page courante.
• Le standard CORS décrit de nouvelles entêtes HTTP qui offrent aux
navigateurs et aux serveurs un moyen de faire une requête vers une URL
distante uniquement s'ils en ont l'autorisation. Bien que certaines validations
et autorisations peuvent être effectuées par le serveur, il est généralement de
la responsabilité du navigateur de supporter ces entêtes et d'honorer les
restrictions qu'elles imposent.
CROSS-ORIGIN RESOURCE SHARING 
(CORS) 
 MENACES SUR LES WEB SERVICES

• L’évolution rapide de l’écosystème du Web génére sans cesse de nouvelles menaces sur les
APIs.

• Le Open Source Web Application Security Project (OWASP) met régulièrement à jour la liste
des différents dangers et failles de sécurité et diffuse des conseils aux entreprises pour mieux
protéger leurs applications Web.
 MENACES SUR LES WEB SERVICES

DDoS

Les dénis de services distribués sont un ensemble de techniques d’attaques (surtout contre les
serveurs) dont le principe est de saturer la machine attaquée, par exemple en lui envoyant une
quantité ingérable de requêtes en un minimum de temps.

Certains firewall permettent de protéger les serveurs Web contre ce type d’attaque.

Des intelligences artificielles sensées analyser les requêtes et détecter les situations dangereuses
commencent aussi à être développées.
 MENACES SUR LES WEB SERVICES

CSRF (Cross Site Request Forgery)

C’est une attaque qui vise à faire exécuter une certaine action à un utilisateur authentifié qui
a des droits ou des accès que le hacker n’a pas.
• Les systèmes d’identification par jetons dynamiques ou les captchas sont des outils utilisés
souvent pour empêcher les CSRF,
• Il est également impératif de suivre les règles élémentaires du développement Web et
d’APIs établies par des organismes comme la W3C
MENACES SUR LES WEB SERVICES

Injections SQL
Les infections SQL sont des interférences que produit un hacker sur les requêtes
qu’une application enverra au serveur pour être exécuter au niveau d’une base de
données, soit pour récupérer des données, ou pire, pour altérer le système
d’information.
AUTHENTIFICATION ET AUTORISATION

L'authentification est la vérification des informations d'identification lors de la

tentative de connexion. Ce processus consiste à envoyer les informations
d'identification du client au serveur d'accès distant sous forme de texte brut ou crypté à
l'aide d'un protocole d'authentification.

L'autorisation est la vérification que la tentative d’accès à une ressource ou un service

est autorisée. L'autorisation survient après une authentification réussie.
 AUTHENTIFICATIONS
Authentification basique
 Celle-ci ne demande qu'un nom d'utilisateur et un mot de passe. Le client prend ces
deux identifiants et les transforme en une valeur unique, qu'il passe dans la requête
grâce à un header HTTP appelé Authorization.

Obligation d’utiliser un
cryptage (comme SSL)
pour éviter les attaques
Man in the Middle ce qui
consomme des ressources,
en plus du risque de
sessions restées ouvertes
 AUTHENTIFICATIONS
Authentification par une clé API

Dans cette approche, une valeur générée unique est attribuée à chaque utilisateur pour
la première fois, ce qui signifie que l'utilisateur est connu. Lorsque l'utilisateur tente de
revenir dans le système, sa clé unique (parfois générée à partir de la combinaison
d’informations matériel et de données IP, et parfois générée de manière aléatoire par le
serveur qui les connaît) est utilisée pour prouver qu'il s'agit du même utilisateur
qu'auparavant.
Ce système est très bon en terme de performance et facile à mettre en place, c’est
pourquoi il est très utilisé par les Web APIs.
Cependant c’est une solution peu sécurisée étant donné que tout dépend d’une clé qui
peut-être récupérée sur le réseau (par sniffing) ou une machine non sécurisée (par un
spyware par exp)
 AUTHENTIFICATIONS

Open Authorization (OAuth)

Cette fois, l'utilisateur se connecte à un système. Ce système demandera alors

l'authentification, généralement sous la forme d'un jeton, ou d’un username/password.
L'utilisateur transmettra ensuite cette demande à un serveur d'authentification, qui
rejettera ou autorisera cette authentification. À partir de là, le jeton est fourni à
l'utilisateur, puis au demandeur (le service à sécuriser). Un tel jeton peut ensuite être
vérifié à tout moment, indépendamment de l'utilisateur par le demandeur, aux fins de
validation, et peut être utilisé dans le temps avec une portée et une période de validité
strictement limitées pour OAuth2.

Le fait d’avoir un serveur tiers et un renouvellement

des jetons permet une vraie sécurité et l’introduction
de la notion d’autorisations
 AUTORISATIONS
Open Authorization (OAuth) constitue une bonne solution à mettre en place pour
gérer les droits des utilisateurs en lecture/écriture.

Les SESSIONS
Un mécanisme permettant à certains types de serveurs (comme eux utilisant PHP) de
gérer l’identité des utilisateurs.
Il peut être efficace dans des réseaux limités ou pour un nombre d’utilisateurs restreints,
mais ils obligent les serveurs à conserver des informations en mémoire ce qui peut-être
problématique au cas ou le nombre de clients deviendrait trop important, et c’est contre
le principe stateless des Api Rest.
En plus les systèmes de sessions utilisent les web COOKIES pour identifier le client,
ce qui peut constituer une vulnérabilité à des attaques par sidejacking ou XSS par
exemple.
 AUTORISATIONS
Json Web Tokens (JWT)
JWT ou JSON Web Token est un standard ouvert décrit dans la RFC 7519 qui permet
l’authentification d’un utilisateur à l’aide d’un jeton (token) signé. Le principe est le
suivant :
 AUTORISATIONS
1. Header : La première partie du JWT est le header. Il s’agit d’un objet JSON encodé
en base64 qui représente l’en-tête du token. Il est composé de deux parties :
• Le type du token;
• L’algorithme utilisé pour la signature
exp: {  "typ":"JWT"  , "alg":"HS256" }

2. Payload : La seconde partie du JWT est le payload. Il s’agit tout comme le header,
d’un objet JSON encodé en base64 qui représente cette fois-ci le corps du token. C’est
dans cette partie que l’on mettra les informations de l’utilisateur (identifiant, rôle, etc.)
ou toute autre information utile au serveur. 

Signature : La dernière partie est la signature du token. Il s’agit d’un hash des deux
premières parties du token réalisé en utilisant l’algorithme qui est précisé dans le header
exp: HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), 'secret')
 AUTORISATIONS
L’algorithme utilise une clé secrète (détenue par le serveur), utilisée pour signer les
tokens mais également s’assurer de la validité de ceux-ci en vérifiant leur signature. De
ce fait, si un utilisateur malveillant modifie le contenu du token, la signature ne sera
plus correcte et le jeton sera ainsi rejeté.

Un JWT possède une date d’expiration (propriété “exp” du payload), ainsi lorsqu’un
JWT expiré est envoyé lors d’une requête à l’API, celle-ci renverra une erreur 401
indiquant que le JWT n’est plus valide. La durée de validité d’un JWT va dépendre du
type de données échangées. Elle sera de quelques minutes pour l’échange de données
sensibles à plusieurs heures pour les données non sensibles. 

Afin d’éviter à l’utilisateur de devoir se réauthentifier lorsque le JWT expire, il est

possible d’utiliser un “refresh token”. Lorsque l’utilisateur s’identifie à l’aide de son
couple login/mot de passe, le serveur génère en plus du JWT, un token aléatoire à usage
unique attaché à l’utilisateur.
CHOIX REST/SOAP
 EXEMPLES D’API REST

• Les grands noms de l'informatique proposent des API publiques pour interagir avec leurs services :
• Graph API (Facebook) permet d'interagir avec les données de Facebook (publication, importer des
photos…) ;
• Google API, Google propose des accès pour l'ensemble de ses services. Si l'on prend Maps par exemple,
l'API permet de calculer des trajets, de gérer la conversion de coordonnées GPS/adresses ou encore de
connaitre l'altitude liée à une position ;
• Twitter API permet de lire et d'écrire sur un flux Twitter ;
• Pay permet d'intégrer la solution de paiement PayPal dans son application ;
• GitHub API ;
• Flickr API.
 NOUVELLES TECHNOLOGIES DE WS

• FQL @ Facebook (2007)

GET /fql?
q=SELECT+uid2+FROM+friend+WHERE+uid1=me()&access_token=25az20
1rt401setty
• YQL @ Yahoo (2008)
https://query.yahooapis.com/v1/public/yql?q=select title, link from rss where
url='https://engt.co/2JyTaQP‘ &format=json
&env=store://datatables.org/alltableswithkeys
 NOUVELLES TECHNOLOGIES DE WS

• L’objectif de GraphQL et de découpler la forme de la ressource et la façon dont on

récupère cette ressource.
• Pour arriver à cela, un langage de requête a été ajouté coté client

• Exemple :
GET /graphql?query={ contact(id: "1") { nom, prenom, adresse {
rue, ville } } } { "nom": "Doe", "prenom": "John", "adresse":
{ "rue": "75000", "ville": "Paris", } }

Ce qui permet par exemple d’éviter de créer un trop grand nombre de fichiers coté
serveur pour répondre à des demandes de types différents
 NOUVELLES TECHNOLOGIES DE WS

• GraphQL permet d’intéragir avec un serveur d’API en 3 modes différents:

• fetch (pour lancer de requêtes de lecture)
• subscription (créer un streaming, ce qui permettra par exemple de récupérer
des notifications coté client en cas de changements sur les données du
serveur)
• mutation (faire des requêtes en écriture)

GraphQL n’est pas une norme, mais un projet développer par Facebook, il
en existe d’autres similaires comme Falcor (développé par Netflix)
 LES TECHNOLOGIES UTILISANT REST

• Les plateformes de Cloud

• Le SDN (software Defined Networks)
• Le WebRTC
• La Blockchain
• Les architectures micro-services

Architecture openflow SDN

 RESSOURCES COMPLÉMENTAIRES

• Les architectures distribuées

• Remote Procedure Call
• Les Web Services
• Exemple de réalisation d’un service Web SOAP
• Détails sur les formats XML & JSON
• Concept des architectures REST (Roy Fielding)
• Apprendre à utiliser des Web APIs
• Apprendre JavaScript
• The Open Web Application Security Project (OWASP)
• Site officiel du projet Oauth
• Introduction à GraphQL