Stéphane WOUTERS
https://stephanewouters.fr/
Cloud et Système web
CLIENT
SERVEUR
Logiciel, application web/mobile, site internet, objet connecté...
FTP, API, Base de données...
Client
Serveur
STRATÉGIE CLIENT LÉGER
Serveur
Client
STRATÉGIE CLIENT LOURD
Le client ne s'occupe que de l'affichage.
Exemples :
Un Site web en PHP sans javaScript.
Un accès à un poste teamviewer
La logique métier est côté client.
Exemples :
Une application web javascript connectée à une API.
Un logiciel connecté à une base de donnée.
www.wooclap.com/CLISERV
CLIENT
SERVEUR
PROTOCOLE
Exemples de protocoles utilisés sur le web :
CLIENT
SERVEUR
1. Requête
2. Réponse
HTTP fonctionne par transactions : Le client envoie une requête au serveur, puis le serveur envoie sa réponse
Le serveur ne peut jamais envoyer une requête au client
Exemples d'utilisations :
Servir une page web (html) et ses assets (css/javascript/images/videos...)
HyperText Transfer Protocol Secure
Version sécurisée de HTTP
Permet de chiffrer la connexion grâce à un certificat SSL
CLIENT
SERVEUR
1. Requete
Le client et le serveur échangent via une connexion persistante. Le client et le serveur peuvent s'envoyer un message à tout moment.
CONNECTÉS
Exemples :
Exemples de supports de données utilisés
UNE PIZZA n°1 A 8 EUROS
<order>
<pizza id="1">
<price>3</price>
</pizza>
</order>
{
"orders": [{
"pizza": {
"id": "1",
"price": 3
}
}]
}
product;id;price
pizza;1;3
Pour les API plus complexes, il est utile de structurer la donnée. Les normes les plus connues sont :
Les api peuvent aussi ne pas suivre de protocole existant
On trouvera dans une documentation :
Fonctionne uniquement pour les requêtes GET
Un outil complet : Postman
Difficile d'envoyer des headers personnalisés (authentification...)
Démo
Langage de requête pour les API
GraphQL est un langage de requête pour les API
GRAPHQL
SERVEUR
CLIENT
Intêrets
Typé
Structuré
Hôtel
Destination
Review
hotel {
name: string
description: string
rooms: number
photos: Picture
destinations: Destination[]
}
Différence avec les API classiques
GRAPHQL
CLASSIQUE
Un seul endpoint :
Une route par action :
C'est l'utilisateur qui décide des données qu'il recevra
{
user {
name
}
}
{
"user": {
"name": "John Doe"
}
}
{
"user": {
"name": "John Doe"
"email": "john.doe@gmail.com"
"account" {
"login": "john"
"last_connexion": "27/12/2019"
}
}
}
{
user {
name
email
account {
login
last_connexion
}
}
}
Requête
Réponse
Réponse
Requête
Documentation intégrée (= schéma)
Requête
Réponse
Schéma
I. Pré requis : Génerer une API en SAAS avec GraphCMS
Permet de récupérer des données
Permet de modifier des données
query {
user
}
mutation {
updateReview(data: {
content: "Hello"
}) {
id
}
}
Query & Mutations GraphQL (II. et III.)