À propos de ce cours
Comprenez le dialogue client-serveur et le protocole HTTP : anatomie d'une URL, d'une requête et d'une réponse, en-têtes, méthodes GET, POST, PUT, PATCH et DELETE, méthodes sûres et idempotentes, codes de statut, format JSON, principes des API REST et correspondance CRUD, CORS, HTTP/2 et HTTP/3, observation des requêtes avec l'onglet Réseau et curl. Avec des activités corrigées.
-
Objectifs
- Comprendre le dialogue client / serveur et le rôle du protocole HTTP.
- Lire une URL, une requête et une réponse HTTP : méthode, en-têtes, corps et code de statut.
- Connaître les méthodes
GET,POST,PUT,PATCHetDELETEet les principaux codes de statut. - Comprendre ce qu'est une API REST et le format JSON.
- Observer de vraies requêtes avec les outils de développement et la commande
curl.
-
Le dialogue client / serveur
- Quand vous ouvrez une page, votre navigateur (le client) envoie une requête à un ordinateur distant (le serveur), qui renvoie une réponse: une page HTML, une image, un fichier CSS, ou des données.
- Ce dialogue suit des règles communes : le protocole HTTP (HyperText Transfer Protocol), créé par Tim Berners-Lee au CERN au début des années 1990. HTTPS est la même chose, mais chiffrée (protocole TLS) : personne ne peut lire ni modifier les échanges en chemin. Aujourd'hui, la quasi-totalité des sites l'utilisent, et les navigateurs signalent les pages en HTTP comme « non sécurisées ».
- HTTP est sans état (stateless) : chaque requête est indépendante, le serveur ne se souvient pas de la précédente. Pour reconnaître un utilisateur connecté, on ajoute à chaque requête un cookie de session ou un jeton (chapitre 20 et leçon 5).
- Une page web moderne déclenche souvent des dizaines de requêtes : le HTML, puis chaque feuille CSS, chaque script, chaque image, chaque police… et les données demandées par JavaScript. C'est ce dernier cas qui nous intéresse dans ce chapitre : JavaScript peut lui-même envoyer des requêtes et utiliser les réponses sans recharger la page. C'est le principe d'Ajax (leçons 2 et 3) et de
fetch(leçons 4 à 6).
-
Anatomie d'une URL

| Partie | Exemple | Rôle |
|---|---|---|
| Protocole | https | Façon de communiquer (chiffrée ici) |
| Domaine (hôte) | api.centre.tn | Serveur à contacter (traduit en adresse IP par le DNS) |
| Port | :443 | « Porte » du serveur ; sous-entendu : 443 pour HTTPS, 80 pour HTTP |
| Chemin | /v1/stagiaires | La ressource demandée |
| Paramètres de requête | ?groupe=DEV-101&page=2 | Options : filtre, tri, page… (paires clé=valeur séparées par &) |
| Ancre (fragment) | #haut | Position dans la page ; jamais envoyée au serveur |
- Les caractères spéciaux (espaces, accents,
&,?) doivent être encodés:GabèsdevientGab%C3%A8s. En JavaScript, l'objetURLSearchParamss'en charge (leçon 4) :
const params = new URLSearchParams({ ville: "Gabès", jours: 3 });
console.log(params.toString()); // "ville=Gab%C3%A8s&jours=3"
const url = new URL("https://api.centre.tn/v1/stagiaires?groupe=DEV-101&page=2");
console.log(url.hostname); // "api.centre.tn"
console.log(url.pathname); // "/v1/stagiaires"
console.log(url.searchParams.get("page")); // "2"
La requête HTTP
Une requête est un simple texte composé de trois parties :
- La ligne de requête: la méthode (ce que l'on veut faire), le chemin et la version d'HTTP. Exemple :
GET /v1/stagiaires HTTP/1.1. - Les en-têtes (headers) : des informations complémentaires sous la forme
Nom: valeur. - Le corps (body), facultatif : les données envoyées, par exemple un formulaire ou un objet JSON. Une requête
GETn'a pas de corps.
| En-tête de requête | Exemple | Rôle |
|---|---|---|
Host | api.centre.tn | Domaine visé (un même serveur héberge souvent plusieurs sites) |
Accept | application/json | Format de réponse souhaité |
Content-Type | application/json | Format du corps envoyé |
Authorization | Bearer eyJhbGci… | Preuve d'identité (jeton) |
Cookie | session=8f3a… | Cookies du site (ajoutés automatiquement par le navigateur) |
Accept-Language | fr-FR,fr;q=0.9,ar;q=0.8 | Langues préférées de l'utilisateur |
User-Agent | Mozilla/5.0 … Chrome/… | Navigateur et système utilisés |
Les méthodes HTTP
| Méthode | Usage | Corps | Sûre | Idempotente |
|---|---|---|---|---|
GET | Lire une ressource | Non | Oui | Oui |
POST | Créer une ressource, envoyer un formulaire, déclencher une action | Oui | Non | Non |
PUT | Remplacer entièrement une ressource | Oui | Non | Oui |
PATCH | Modifier une partie d'une ressource | Oui | Non | Pas forcément |
DELETE | Supprimer une ressource | Rarement | Non | Oui |
HEAD | Comme GET, mais sans le corps (taille, date de modification) | Non | Oui | Oui |
OPTIONS | Demander ce qui est permis (utilisée automatiquement par CORS) | Non | Oui | Oui |
- Sûre: ne modifie rien sur le serveur. On peut l'appeler sans risque, la mettre en cache, la précharger.
- Idempotente: l'effet est le même qu'on l'envoie une ou dix fois. Supprimer deux fois le stagiaire 42 donne le même résultat ; envoyer deux fois un
POSTcrée deux stagiaires. C'est pourquoi un navigateur demande confirmation avant de renvoyer un formulaire quand on recharge la page.
La réponse HTTP et les codes de statut
- La réponse a la même structure : une ligne de statut (
HTTP/1.1 200 OK), des en-têtes et un corps (le contenu). - Le code de statut est un nombre à trois chiffres. Le premier chiffre indique la famille :
| Code | Nom | Signification |
|---|---|---|
200 | OK | Tout s'est bien passé |
201 | Created | Ressource créée (après un POST) |
204 | No Content | Réussi, mais rien à renvoyer (souvent après un DELETE) |
301 / 308 | Moved Permanently | La ressource a changé d'adresse définitivement |
304 | Not Modified | La copie en cache est toujours valable |
400 | Bad Request | Requête mal formée (JSON invalide, paramètre manquant) |
401 | Unauthorized | Non authentifié : il faut se connecter |
403 | Forbidden | Authentifié, mais pas autorisé |
404 | Not Found | Ressource introuvable |
409 | Conflict | Conflit (par exemple : adresse e-mail déjà utilisée) |
422 | Unprocessable Content | Données refusées par la validation (note de 25/20…) |
429 | Too Many Requests | Trop de requêtes : quota dépassé, il faut patienter |
500 | Internal Server Error | Bogue côté serveur |
502 / 503 / 504 | Bad Gateway / Service Unavailable / Gateway Timeout | Serveur surchargé, en maintenance ou qui ne répond pas |
- Règle simple : 4xx = l'erreur vient du client (corriger la requête), 5xx = l'erreur vient du serveur (réessayer plus tard, prévenir l'administrateur).
- En-têtes de réponse courants :
Content-Type(format du corps :text/html,application/json,image/png…),Content-Length(taille),Cache-Control(durée de mise en cache),Location(adresse de la ressource créée ou de la redirection),Set-Cookie,Access-Control-Allow-Origin(CORS).
-
JSON : le format des données
- JSON (JavaScript Object Notation) est le format d'échange de données utilisé par presque toutes les API web. Il ressemble aux objets JavaScript, avec des règles plus strictes : clés entre guillemets doubles, pas de virgule finale, pas de commentaires, et seulement six types de valeurs (texte, nombre, booléen,
null, tableau, objet).
{ "id": 42, "nom": "Ines Haddad", "groupe": "DEV-102", "moyenne": 14.5, "diplome": false, "modules": ["HTML", "CSS", "JavaScript"], "tuteur": { "nom": "M. Hajji", "email": "tuteur@centre.tn" }, "telephone": null }- En JavaScript, deux fonctions font la conversion :
JSON.stringify(objet)transforme un objet en texte JSON (pour l'envoyer),JSON.parse(texte)fait l'inverse (pour l'utiliser). Avecfetch,reponse.json()appelleJSON.parsepour vous. - Une date n'a pas de type JSON : on l'écrit en texte au format ISO 8601 (
"2026-11-12T09:30:00Z"). - Avant JSON, les échanges se faisaient en XML (d'où le X de « Ajax » et de « XMLHttpRequest ») : plus verbeux, plus lourd à lire en JavaScript. JSON l'a remplacé dans les API web dès les années 2010.
- JSON (JavaScript Object Notation) est le format d'échange de données utilisé par presque toutes les API web. Il ressemble aux objets JavaScript, avec des règles plus strictes : clés entre guillemets doubles, pas de virgule finale, pas de commentaires, et seulement six types de valeurs (texte, nombre, booléen,
-
Qu'est-ce qu'une API REST ?
- Une API (Application Programming Interface) est une porte d'entrée qu'un programme offre aux autres programmes. Une API web est une API accessible par HTTP : au lieu de renvoyer des pages HTML pour des humains, elle renvoie des données (en JSON) pour des programmes.
- REST (REpresentational State Transfer), décrit par Roy Fielding en 2000, est un style d'organisation des API web, devenu la norme de fait. Ses principes :
Principe En pratique Tout est ressource, désignée par une URL /stagiaires(la collection),/stagiaires/42(un élément),/groupes/DEV-101/stagiaires(une sous-collection)Les méthodes HTTP indiquent l'action Des noms dans l'URL, jamais des verbes : DELETE /stagiaires/42et nonGET /supprimerStagiaire?id=42Les codes de statut indiquent le résultat 201après une création,404si l'élément n'existe pas,422si les données sont invalidesSans état Chaque requête contient tout ce qu'il faut (dont le jeton d'authentification) Représentations La même ressource peut être fournie en JSON, en XML, en CSV… selon l'en-tête AcceptRéponses cachables Le serveur indique combien de temps une réponse reste valable ( Cache-Control)
- Les quatre opérations de base sur des données, CRUD (Create, Read, Update, Delete), correspondent donc à
POST,GET,PUT/PATCHetDELETE. - Bonnes pratiques d'URL : noms au pluriel, en minuscules avec des tirets (
/sessions-examen), un numéro de version (/v1/) pour pouvoir faire évoluer l'API sans casser les applications existantes, des paramètres pour filtrer, trier et paginer (/stagiaires?groupe=DEV-101&tri=-moyenne&page=2). - Il existe d'autres styles d'API : GraphQL (une seule adresse, le client décrit exactement les données voulues), gRPC (entre serveurs, très rapide), les WebSockets (connexion permanente pour le temps réel : chat, notifications). REST reste le plus répandu et le plus simple à apprendre.
-
CORS : pourquoi une API peut refuser votre page
- Par sécurité, le navigateur applique la politique de même origine: un script de
http://127.0.0.1:5500ne peut pas lire la réponse d'une requête vershttps://api.autre-site.com… sauf si ce serveur l'autorise explicitement. - Cette autorisation s'appelle CORS (Cross-Origin Resource Sharing) : le serveur répond avec l'en-tête
Access-Control-Allow-Origin: *(tout le monde) ouAccess-Control-Allow-Origin: https://mon-site.tn(un site précis). Pour les requêtes « non simples » (PUT, DELETE, JSON envoyé…), le navigateur envoie d'abord une requêteOPTIONSde vérification, dite preflight. - Si l'autorisation manque, la console affiche une erreur « blocked by CORS policy ». Ce n'est pas un bogue de votre code: seule la configuration du serveur peut le corriger. Les API publiques prévues pour le web (Open-Meteo, JSONPlaceholder…) envoient cet en-tête.
- Par sécurité, le navigateur applique la politique de même origine: un script de
-
HTTP aujourd'hui : HTTP/2 et HTTP/3
- HTTP/1.1 (1997) traite les requêtes une par une sur chaque connexion.
- HTTP/2 (2015) fait passer de nombreuses requêtes en même temps sur une seule connexion et compresse les en-têtes.
- HTTP/3 (normalisé en 2022) remplace TCP par QUIC, un transport plus rapide à établir et plus résistant aux réseaux mobiles instables. Il est utilisé par une large part des grands sites.
- Pour vous, développeur, rien ne change : les méthodes, en-têtes et codes de statut restent les mêmes, et le navigateur choisit la version automatiquement (colonne Protocol de l'onglet Réseau :
h2,h3).
-
Observer HTTP : l'onglet Réseau et curl
- DevTools → Réseau (Network): ouvrez-le avant de charger la page. Chaque ligne est une requête ; cliquez dessus pour voir les onglets Headers (méthode, URL, statut, en-têtes), Payload (corps envoyé), Preview et Response (corps reçu), Timing (durée). Le filtre Fetch/XHR ne garde que les requêtes faites par JavaScript.
- Clic droit sur une requête → Copy → Copy as fetch: DevTools écrit pour vous le code JavaScript équivalent. Copy as cURL donne la commande en ligne.
- curl (installé avec Windows 10/11, macOS et Linux) envoie des requêtes depuis un terminal :
# GET : afficher la réponse avec les en-têtes (-i) curl -i https://jsonplaceholder.typicode.com/users/1 # POST avec un corps JSON curl -X POST https://jsonplaceholder.typicode.com/posts ^ -H "Content-Type: application/json" ^ -d "{\"title\": \"Bonjour\", \"userId\": 1}" # (sous Windows, ^ continue la ligne ; sous Linux et macOS, utilisez \)- Des outils graphiques comme Bruno, Insomnia ou Postman, ou l'extension REST Client de VS Code, permettent aussi de tester une API sans écrire de code.
-
Activités
Activité 1 : décortiquer des URL
- Pour l'URL
https://www.google.com/search?q=formation+javascript&hl=fr#resultats, donnez le protocole, le domaine, le port utilisé, le chemin, les paramètres et l'ancre. - Dans la console, utilisez
new URL(...)pour vérifier vos réponses, puis ajoutez le paramètrepage=2avecurl.searchParams.set()et affichezurl.href.
Activité 2 : l'onglet Réseau
- Ouvrez l'onglet Réseau puis la page https://jsonplaceholder.typicode.com/users. Notez la méthode, le code de statut, le
Content-Typede la réponse, sa taille et sa durée. - Rechargez la page d'accueil d'un site d'information : combien de requêtes ? Quel est le type de fichier le plus fréquent ? Trouvez une requête de statut 304 ou servie depuis le cache.
- Demandez
https://jsonplaceholder.typicode.com/users/9999: quel code obtenez-vous ?
Activité 3 : concevoir une API REST
- Le centre veut une API pour gérer ses formations et les inscriptions des stagiaires à ces formations. Écrivez, pour chaque besoin, la méthode et l'URL :
- lister les formations ; voir la formation 7 ; créer une formation ; changer seulement la durée de la formation 7 ; supprimer la formation 7 ; lister les inscrits de la formation 7 ; inscrire le stagiaire 42 à la formation 7 ; lister les formations de niveau BTS, triées par date de début.
- Pour chacune, indiquez le code de statut attendu en cas de succès.
Activité 4 : quel code de statut ?
- Associez un code à chaque situation : le jeton de connexion a expiré ; la note envoyée vaut 25 ; le stagiaire demandé n'existe pas ; le serveur de base de données est en panne ; l'utilisateur a envoyé 500 requêtes en une minute ; un formateur veut modifier les notes d'un groupe qui n'est pas le sien ; la suppression a réussi.
Corrigés. Activité 1 :
https, www.google.com, port 443 (sous-entendu), /search, q=formation+javascript et hl=fr, ancre resultats. Activité 2 : GET, 200, application/json; charset=utf-8; l'utilisateur 9999 donne 404. Activité 3 : GET /formations (200) ; GET /formations/7 (200) ; POST /formations (201) ; PATCH /formations/7 (200) ; DELETE /formations/7 (204) ; GET /formations/7/inscriptions (200) ; POST /formations/7/inscriptions avec {"stagiaireId": 42} dans le corps (201) ; GET /formations?niveau=BTS&tri=dateDebut (200). Activité 4 : 401, 422 (ou 400), 404, 503 (ou 500), 429, 403, 204.À retenir
- HTTP : le client envoie une requête (méthode, URL, en-têtes, corps), le serveur renvoie une réponse (statut, en-têtes, corps). HTTPS la chiffre.
- Méthodes :
GETlire,POSTcréer,PUTremplacer,PATCHmodifier,DELETEsupprimer. - Statuts : 2xx succès, 3xx redirection, 4xx erreur du client, 5xx erreur du serveur.
- Une API REST expose des ressources (URL au pluriel) manipulées avec les méthodes HTTP et échange des données en JSON ; CORS décide si une page d'un autre site peut lire ses réponses.
Sources : MDN Web Docs, WHATWG (XMLHttpRequest, Fetch), IETF, open-meteo.com.