Pourquoi ce sujet est important
Chaque navigation, appel d’API et chargement d’image repose sur HTTP. Comprendre ce qui circule entre client et serveur permet de diagnostiquer les erreurs, concevoir une API cohérente et éviter des problèmes de cache ou de sécurité.
Anatomie d’une requête
Une requête contient une méthode, une URL, des en-têtes et parfois un corps. L’URL réunit schéma, hôte, port, chemin et paramètres. Les en-têtes décrivent notamment format accepté, authentification, cache et origine. Le corps transporte souvent JSON, formulaire ou fichier.
Anatomie d’une réponse
Le serveur renvoie un code de statut, des en-têtes et éventuellement un corps. Content-Type indique le format réel. Content-Length ou le transfert en flux décrivent l’envoi. Les en-têtes de cache, cookies et sécurité modifient le comportement du navigateur même si le JSON semble correct.
Méthodes et sémantique
GET lit sans modifier l’état attendu. POST crée ou déclenche une action. PUT remplace généralement une ressource, PATCH la modifie partiellement et DELETE la supprime. La convention aide clients, caches et outils. Une méthode dite idempotente peut être répétée sans effet métier supplémentaire.
Lire les statuts
Les 2xx indiquent un succès, 3xx une redirection, 4xx un problème côté requête et 5xx une erreur serveur. Utilisez 400 pour une requête invalide, 401 pour une authentification requise, 403 pour un refus malgré l’identité et 404 pour une ressource absente. Ne renvoyez pas toujours 200 avec une erreur dans le corps.
Cache et revalidation
Cache-Control définit durée et partage. ETag et Last-Modified permettent une requête conditionnelle et une réponse 304. Les contenus privés ne doivent pas être placés dans un cache public. Comprenez aussi le cache CDN, navigateur et framework afin d’éviter des données périmées.
Cookies, CORS et HTTPS
Un cookie possède domaine, chemin, durée et attributs Secure, HttpOnly et SameSite. CORS contrôle les requêtes du navigateur entre origines, pas les appels serveur-à-serveur. HTTPS chiffre le transport et authentifie le serveur ; il doit être la norme.
Diagnostiquer
Utilisez l’onglet Network, curl ou un client API. Vérifiez URL finale, méthode, statut, redirections, headers, timing et corps. Distinguez DNS, connexion, TLS, temps serveur et téléchargement. Un identifiant de corrélation aide à relier client et logs serveur.
Exemple concret
Un formulaire affiche “erreur réseau”. Dans Network, la requête OPTIONS CORS échoue avant le POST. Le serveur autorise la mauvaise origine. Corriger le JSON n’aurait aucun effet : l’analyse de la méthode, du statut et des en-têtes révèle la vraie cause.
Les erreurs fréquentes
- utiliser GET pour modifier des données
- renvoyer 200 pour toutes les erreurs
- confondre 401 et 403
- mettre des données privées dans un cache public
- croire que CORS protège une API contre tous les clients
- journaliser des tokens Authorization
Checklist
- [ ] Méthodes cohérentes
- [ ] Statuts adaptés
- [ ] Content-Type correct
- [ ] Erreurs structurées
- [ ] Cache explicite
- [ ] Cookies sécurisés
- [ ] HTTPS obligatoire
- [ ] Identifiant de corrélation
FAQ
HTTP et HTTPS sont-ils différents ?
HTTPS est HTTP transporté dans une connexion TLS chiffrée et authentifiée.
Pourquoi une requête OPTIONS apparaît-elle ?
Le navigateur effectue parfois un preflight CORS avant une requête entre origines.
POST est-il toujours non idempotent ?
Par sémantique générale oui, mais une clé d’idempotence peut empêcher les doublons métier.
Que signifie 304 ?
La ressource n’a pas changé selon le validateur ; le client peut réutiliser sa copie en cache.