Requête, réponse, statuts

Prérequis (cursus dev) : requête et réponse, méthodes et statuts, curl pas à pas.

Pourquoi

HTTP, c'est 99 % du trafic que tu administreras. Savoir lire une requête/réponse brute, c'est diagnostiquer sans deviner — et comprendre ce que ton reverse proxy relaie vraiment.

Concepts

• Requête : méthode + chemin + version (GET /api/health HTTP/1.1), headers (Host, User-Agent, Authorization…), body optionnel. Réponse : version + statut + headers + body.
• Statuts par famille : 2xx succès (200 OK, 201 créé, 204 vide), 3xx redirection (301 permanente — cachée !, 302 temporaire), 4xx faute du client (400, 401 non authentifié, 403 interdit, 404), 5xx faute du serveur (500, 502 mauvaise passerelle — le proxy parle mais l'app derrière est morte, 503 indisponible).
• Sans état : chaque requête est indépendante (cf. cours 6.3 : stateless). La « session » est reconstruite par dessus (cookie, token).

Exemple : lire comme un pro

curl -sI https://example.com        # -I = headers seuls (HEAD) : statut + redirections
curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/api/health

301 vers un domaine qui re-301 vers le premier = boucle de redirection (config proxy) : curl -L --max-redirs 3 pour voir sans tourner en rond.

Cas réel

API qui « répond 200 avec une erreur » : statut 200 + body {"error": ...}. Le monitoring au statut est vert pendant que les users sont bloqués. Règle : les erreurs métier portent un statut 4xx/5xx — jamais 200 + erreur déguisée.

Pièges

• 301 cachée par le navigateur : après un test foireux, vider le cache ou tester en privé avant de conclure.
• 502 vs 503 : 502 = proxy OK mais app KO (aller voir l'app) ; 503 = service qui se déclare indisponible (maintenance, surcharge).
• Lire le body sans le statut (ou l'inverse) : les deux ensemble, toujours.

À retenir

Requête = méthode + chemin + headers ; statuts par famille ; 502 = app derrière morte ; jamais d'erreur déguisée en 200.