Ce qui se passe vraiment entre le navigateur et le serveur

Tout le développement web tient dans un aller-retour. Si ce modèle est clair, le reste s'organise.

Le cycle

Le navigateur envoie une requête. Le serveur renvoie une réponse. C'est tout, et cela recommence à chaque action.

Une requête contient :

Une méthode — GET pour lire, POST pour créer, PUT ou PATCH pour modifier, DELETE pour supprimer. Une adresse — le chemin demandé, avec d'éventuels paramètres. Des en-têtes — informations sur le client, le format attendu, les jetons d'authentification. Un corps, pour les méthodes qui envoient des données.

Une réponse contient :

Un code de statut — 200 pour un succès, 301 et 302 pour une redirection, 400 pour une requête mal formée, 401 pour une authentification manquante, 403 pour un accès refusé, 404 pour une ressource absente, 500 pour une erreur du serveur. Des en-têtes. Un corps — la page, les données, l'image.

La propriété qui change tout : l'absence de mémoire

Le protocole ne se souvient de rien. Chaque requête est indépendante des précédentes.

Le serveur ne sait pas que la requête qui arrive vient de la même personne que la précédente. Il faut le lui dire, à chaque fois.

C'est pour cela que les sessions, les cookies et les jetons existent. Ce ne sont pas des complications : ce sont les mécanismes qui reconstruisent une continuité que le protocole ne fournit pas.

Retenez cette phrase : tout état doit être transporté ou retrouvé à chaque requête.

La distinction GET et POST

Elle n'est pas cosmétique.

GET doit être sans effet de bord : il lit, il ne modifie rien. Ses paramètres sont dans l'adresse, donc visibles, enregistrés dans l'historique, dans les journaux du serveur et dans les statistiques.

Conséquence pratique majeure : ne mettez jamais de donnée sensible dans une adresse. Ni mot de passe, ni jeton, ni information personnelle. Elle sera enregistrée à plusieurs endroits que vous ne contrôlez pas.

POST modifie. Ses données sont dans le corps de la requête. Une page obtenue par POST ne se recharge pas sans réenvoyer les données — d'où le motif classique : après un POST réussi, on redirige vers une page en GET.

Où le code s'exécute

C'est la deuxième notion fondamentale.

Le code serveur s'exécute sur votre machine, avant l'envoi. L'utilisateur ne le voit pas et ne peut pas le modifier.

Le code client s'exécute dans le navigateur de l'utilisateur. Il le voit, il peut le lire, le modifier, le désactiver.

La conséquence est absolue : rien de ce qui vient du client n'est digne de confiance.

Une validation faite en JavaScript est un confort d'utilisation, jamais une sécurité. Un champ caché n'est pas caché. Un bouton désactivé peut être réactivé. Une règle appliquée dans le navigateur peut être contournée en dix secondes.

Toute règle qui compte doit être appliquée sur le serveur. C'est la règle qui protège de la moitié des failles.

Le rendu

Trois approches, et leurs conséquences :

Le rendu serveur — le serveur produit la page complète. Simple, rapide au premier affichage, bien indexé par les moteurs.

Le rendu client — le serveur envoie une page vide et du code ; le navigateur construit la page et va chercher les données. Interactions fluides, premier affichage plus lent, indexation plus délicate.

Le mélange — page initiale rendue par le serveur, puis interactions gérées côté client. C'est ce que font la plupart des applications modernes.

Choisissez selon le besoin : une page de contenu se rend côté serveur, une application interactive côté client.

Les codes de statut, à utiliser correctement

Beaucoup de développeurs renvoient 200 pour tout, avec un message d'erreur dans le corps. C'est une erreur : les clients, les caches et les outils de surveillance s'appuient sur le statut.

Renvoyez 404 pour une ressource absente, 401 quand l'authentification manque, 403 quand elle est présente mais insuffisante, 422 pour une donnée invalide, 500 pour une erreur de votre côté.

Les outils de développement du navigateur

Ouvrez l'onglet réseau et regardez une page se charger.

Vous verrez chaque requête, son statut, ses en-têtes, son temps de réponse et sa taille. C'est le meilleur outil d'apprentissage du modèle, il est gratuit, et il est déjà installé.

Passez une heure à observer des requêtes réelles avant d'écrire du code. Cela économise des semaines de malentendus.