Le web, c'est une conversation
Depuis le début du cours, ton code PHP reçoit des $_GET, des $_POST, renvoie du HTML… mais d'où ça vient, concrètement ? À chaque fois que tu tapes une URL ou que tu cliques sur un lien, ton navigateur envoie une requête à un serveur, et le serveur renvoie une réponse. Tout le web tient dans cet aller-retour, et son langage s'appelle HTTP.
Comprendre cet aller-retour, c'est comprendre physiquement ce qui se passe : tu n'auras plus à mémoriser, tu sauras déduire où trouver une info et pourquoi ça marche (ou pas).
Ce que contient une requête (et une réponse)
Une requête, c'est trois choses (parfois quatre) :
- une méthode (le verbe :
GET,POST…) qui dit ce qu'on veut faire ; - une URL (l'adresse de la ressource visée) ;
- des en-têtes (headers) : des métadonnées (type de contenu, cookies, identité…) ;
- parfois un corps (body) : les données envoyées (le contenu d'un formulaire, du JSON…).
La réponse a la même forme : un code de statut (a-t-on réussi ?), des en-têtes, et un corps (le HTML de la page, ou du JSON).
Les méthodes et le CRUD
La méthode décrit l'intention. Les quatre verbes principaux correspondent aux quatre opérations de base sur des données, le CRUD (Create, Read, Update, Delete) :
| Méthode | CRUD | Intention | Exemple |
|---|---|---|---|
GET | Read | Lire, récupérer | Afficher la liste des produits |
POST | Create | Créer | Envoyer un formulaire, créer un compte |
PUT / PATCH | Update | Modifier | Mettre à jour un profil |
DELETE | Delete | Supprimer | Supprimer un message |
Dans le cours, tu n'as croisé que GET et POST (les formulaires HTML ne savent envoyer que ces deux-là). PUT et DELETE arrivent quand on construit des API, où chaque verbe a un sens précis.
Les codes de statut : la réponse en un nombre
Le serveur résume le résultat par un nombre à trois chiffres. Le premier chiffre donne la famille :
Le célèbre 404 n'est donc pas un bug mystérieux : c'est juste « cette ressource n'existe pas ». Et un 500 veut dire « ton code PHP a planté » — direction les logs du serveur.
Les en-têtes (headers) : l'enveloppe, pas la lettre
Les en-têtes sont des paires clé : valeur qui accompagnent la requête et la réponse, sans faire partie du contenu. Quelques-uns que tu rencontreras :
Content-Type: text/htmlouapplication/json— le type du corps.Set-Cookie: …— le serveur dépose un cookie (souviens-toi des sessions : c'est par là que voyage l'identifiant).Authorization: …— l'identité/le jeton de l'utilisateur, pour les API.Location: /connexion— accompagne une redirection 3xx.
C'est exactement pour ça que session_start() doit s'exécuter avant tout HTML : déposer un cookie est un en-tête, et les en-têtes partent avant le corps. Une fois le corps commencé, trop tard : « headers already sent ».
HTTP est « sans mémoire » (stateless)
Point crucial : chaque requête est indépendante. Le serveur ne se « souvient » pas de ta requête précédente : il répond, puis oublie. C'est ce qu'on appelle stateless (sans état).
D'où une question : comment un site sait-il que tu es toujours connecté de page en page, si chaque requête repart de zéro ? Réponse : on rajoute volontairement de la mémoire par-dessus, avec les cookies (côté navigateur) et les sessions (côté serveur). Tu vois comme tout se recoud : HTTP oublie, les sessions se souviennent.
Le vocabulaire du métier
Ces mots reviennent sans cesse en entreprise. Tu n'as pas à les maîtriser aujourd'hui, juste à savoir ce qu'ils désignent :
- API : une porte d'entrée pour que des programmes se parlent (souvent en JSON plutôt qu'en HTML).
- REST : une façon répandue de concevoir une API, en utilisant les méthodes HTTP (GET/POST/PUT/DELETE) sur des ressources.
- Endpoint : une URL précise de l'API (ex.
/api/produits/42). - Payload : les données utiles envoyées dans le corps d'une requête.
- Headless : un site « sans tête » — le back-end ne sert que des données (une API), et l'affichage est géré séparément par un autre front (souvent en JavaScript). On sépare le cerveau (données) du visage (affichage).
- CORS : les règles qui décident si un site A a le droit d'appeler l'API d'un site B depuis le navigateur.
Tout voir soi-même : l'onglet Network
Le plus beau, c'est que tu peux observer chaque requête en direct, dans ton navigateur :
- Ouvre les outils de développement :
F12(ou clic droit → « Inspecter »). - Va dans l'onglet Network (« Réseau »).
- Recharge la page : la liste se remplit de toutes les requêtes (la page, les images, les scripts…).
- Clique sur une ligne : tu vois sa méthode, son code de statut, ses en-têtes (requête et réponse) et le corps de la réponse.
C'est l'outil n°1 pour déboguer le web : « ma requête part-elle vraiment ? avec quelles données ? le serveur répond quoi ? ». Avant de deviner, ouvre Network et regarde.
Tu demandes à l'IA de rediriger l'utilisateur vers la page de connexion s'il n'est pas identifié. Elle te propose ce code. Ton rôle de relecteur : l'accepter tel quel ou le rejeter, et dire pourquoi.
if (!isset($_SESSION['user'])) {
header("Location: /connexion");
}
// ... suite : on affiche la page privée
echo "Bienvenue dans votre espace privé";
header("Location: …") envoie bien l'en-tête de redirection 3xx, mais PHP continue d'exécuter les lignes suivantes : le echo part dans le corps de la réponse. Résultat, la page privée est calculée (et parfois affichée) alors qu'on voulait justement bloquer l'accès. Le réflexe pro : toujours exit; juste après une redirection (header("Location: /connexion"); exit;) pour stopper net le script.Sans remonter dans la leçon : que contient une requête HTTP (cite au moins deux éléments), et que veut dire la famille des codes 4xx ?
GET, POST…), une URL, des en-têtes, et parfois un corps (les données envoyées). La famille 4xx signale une erreur côté client : la requête est fautive (ex. 404 ressource introuvable, 403 interdit). À distinguer du 5xx, qui est une erreur côté serveur.The web is a conversation
Throughout this course, your PHP code receives $_GET, $_POST, returns HTML… but where does it actually come from? Every time you type a URL or click a link, your browser sends a request to a server, and the server sends back a response. The whole web fits in that round trip, and its language is called HTTP.
Understanding that round trip means understanding physically what happens: you won't have to memorize, you'll be able to deduce where to find info and why it works (or not).
What a request (and a response) contains
A request is three things (sometimes four):
- a method (the verb:
GET,POST…) saying what you want to do; - a URL (the address of the target resource);
- headers: metadata (content type, cookies, identity…);
- sometimes a body: the data sent (a form's content, JSON…).
The response has the same shape: a status code (did it work?), headers, and a body (the page's HTML, or JSON).
Methods and CRUD
The method describes the intent. The four main verbs map to the four basic operations on data, the CRUD (Create, Read, Update, Delete):
| Method | CRUD | Intent | Example |
|---|---|---|---|
GET | Read | Read, fetch | Show the product list |
POST | Create | Create | Submit a form, create an account |
PUT / PATCH | Update | Modify | Update a profile |
DELETE | Delete | Delete | Delete a message |
In this course you only met GET and POST (HTML forms can only send those two). PUT and DELETE show up when building APIs, where each verb has a precise meaning.
Status codes: the response in one number
The server sums up the result with a three-digit number. The first digit gives the family:
So the famous 404 isn't a mysterious bug: it just means "this resource doesn't exist". And a 500 means "your PHP code crashed" — head to the server logs.
Headers: the envelope, not the letter
Headers are key: value pairs that travel with the request and the response, without being part of the content. A few you'll meet:
Content-Type: text/htmlorapplication/json— the type of the body.Set-Cookie: …— the server drops a cookie (remember sessions: that's how the identifier travels).Authorization: …— the user's identity/token, for APIs.Location: /login— accompanies a 3xx redirect.
That's exactly why session_start() must run before any HTML: dropping a cookie is a header, and headers go out before the body. Once the body has started, too late: "headers already sent".
HTTP is "stateless"
Crucial point: each request is independent. The server doesn't "remember" your previous request: it answers, then forgets. That's what stateless means.
Hence a question: how does a site know you're still logged in from page to page, if each request starts fresh? Answer: we deliberately add memory on top, with cookies (browser side) and sessions (server side). See how it all ties together: HTTP forgets, sessions remember.
The professional vocabulary
These words come up constantly at work. You don't need to master them today, just know what they refer to:
- API: a doorway for programs to talk to each other (often in JSON rather than HTML).
- REST: a widespread way to design an API, using the HTTP methods (GET/POST/PUT/DELETE) on resources.
- Endpoint: a specific API URL (e.g.
/api/products/42). - Payload: the useful data sent in a request's body.
- Headless: a "headless" site — the back-end only serves data (an API), and the display is handled separately by another front (often in JavaScript). You split the brain (data) from the face (display).
- CORS: the rules deciding whether site A may call site B's API from the browser.
See it yourself: the Network tab
The best part: you can watch every request live, in your browser:
- Open the developer tools:
F12(or right-click → "Inspect"). - Go to the Network tab.
- Reload the page: the list fills with all the requests (the page, images, scripts…).
- Click a row: you see its method, its status code, its headers (request and response) and the response body.
It's the #1 tool to debug the web: "is my request actually sent? with what data? what does the server reply?". Before guessing, open Network and look.
You've covered the whole PHP loop: display, process, remember, and talk to APIs. But behind every database hides a language of its own. The SQL course teaches you to store and query your data for real, without leaning on PHP.
Discover SQL →