LES WEB SERVICES

S E D D I K I LY E S ( I N G É N I E R I E D E S S E RV I C E S W E B )
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

8
WEB SOCKETS

9
WEB SOCKETS

10
 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 autres 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