2.4Créer un serveur HTTP natif
Node est largement utilisé pour créer des serveurs web et des API — et il peut le faire avec son module natif http, sans aucune dépendance. Comprendre le serveur HTTP « à la main » AVANT d'utiliser un framework comme Express est très formateur : cela révèle ce qu'Express (section 3-1) simplifie, et démystifie ce qui se passe réellement. Le principe : on crée un serveur avec http.createServer(), en lui passant une fonction qui sera appelée à CHAQUE requête entrante — cette fonction reçoit deux objets essentiels : req (request, la requête du client : sa méthode GET/POST, son URL, ses en-têtes, son corps) et res (response, la réponse qu'on va construire et renvoyer au client). Puis on démarre le serveur avec .listen(port) pour qu'il écoute les connexions sur un port donné (ex. 3000). C'est tout : quelques lignes pour un serveur web fonctionnel.
Détaillons le traitement d'une requête. L'objet req fournit les informations de la requête : req.method (GET, POST, PUT, DELETE…), req.url (le chemin demandé, ex. /users), req.headers (les en-têtes). Pour le corps d'une requête POST (les données envoyées), req est un stream (section 2-3) qu'on lit par morceaux — l'un des aspects qu'Express simplifiera. L'objet res sert à construire la réponse : res.statusCode = 200 (le code de statut HTTP), res.setHeader('Content-Type', 'application/json') (les en-têtes de réponse, notamment le type de contenu), res.write(...) et res.end(...) (envoyer le corps et terminer la réponse). Il faut connaître les bases du protocole HTTP : les méthodes (GET pour lire, POST pour créer, PUT/PATCH pour modifier, DELETE pour supprimer — le vocabulaire des API REST, section 4-1), les codes de statut (200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Internal Server Error…), les en-têtes (métadonnées : type de contenu, authentification, cache…). En créant un serveur natif, on gère TOUT à la main : router selon l'URL et la méthode (une cascade de if), parser le corps, définir les en-têtes, gérer les erreurs — ce qui devient vite fastidieux pour une vraie application. C'est précisément là qu'Express intervient : il fournit un routage élégant, le parsing du corps, la gestion des middlewares, etc. — mais tout cela repose SUR le module http. Créer un serveur natif est donc un exercice fondateur : il vous fait comprendre le socle (req/res, HTTP, ports) sur lequel tout framework Node est bâti, et vous fait apprécier ce qu'un framework apporte. Vous n'écrirez pas de serveurs natifs en production (vous utiliserez Express ou équivalent), mais cette compréhension du « sous le capot » est précieuse — elle fait la différence entre utiliser Express comme une boîte noire et comprendre ce qu'il fait vraiment.
Vocabulaire de la section
- http (module natif)
- Module permettant de créer un serveur web sans dépendance : http.createServer() avec une fonction appelée à chaque requête, puis .listen(port).
- req (request)
- Objet de la requête entrante : méthode (req.method : GET/POST…), chemin (req.url), en-têtes (req.headers), et corps (lu comme un stream pour POST).
- res (response)
- Objet de construction de la réponse : statut (res.statusCode), en-têtes (res.setHeader), corps (res.write/res.end).
- Méthodes & codes HTTP
- Méthodes : GET (lire), POST (créer), PUT/PATCH (modifier), DELETE (supprimer). Codes : 200 OK, 201 Created, 400/401/404 (erreurs client), 500 (erreur serveur).
- Ce qu'Express simplifie
- Le serveur natif gère tout à la main (routage par if, parsing du corps, en-têtes) ; Express fournit routage, parsing, middlewares — mais repose sur le module http.
Pourquoi créer un serveur HTTP natif avant d'utiliser Express ?
En pratique — Créer un serveur HTTP natif
- Créez un serveur avec `http.createServer((req, res) => {...})` et démarrez-le avec `.listen(3000)` ; testez dans le navigateur (localhost:3000).
- Renvoyez une réponse : définissez `res.statusCode`, `res.setHeader('Content-Type', ...)` et terminez avec `res.end('Hello')`.
- Routez « à la main » selon `req.method` et `req.url` (une cascade de if) : renvoyez des réponses différentes selon le chemin.
- Renvoyez du JSON (Content-Type application/json + res.end(JSON.stringify(data))) et constatez combien gérer tout à la main devient vite fastidieux.
Points clés à retenir
- Node crée des serveurs web avec le module natif `http` (sans dépendance) : `http.createServer((req, res) => ...)` puis `.listen(port)`. Formateur AVANT Express.
- `req` = la requête (méthode, url, headers, corps en stream) ; `res` = la réponse (statusCode, setHeader, write/end).
- Connaître HTTP : MÉTHODES (GET/POST/PUT/DELETE) et CODES DE STATUT (200, 201, 400, 401, 404, 500) — le vocabulaire des API REST.
- Le serveur natif gère TOUT à la main (routage par if, parsing du corps, en-têtes) → vite fastidieux ; Express le simplifie mais REPOSE sur http. Comprendre le socle = ne pas subir Express en boîte noire.
Questions fréquentes
Pourquoi apprendre le serveur HTTP natif si je vais utiliser Express de toute façon ?
C'est une excellente question, et la réponse est que comprendre le natif AVANT Express vous rend un bien meilleur développeur — vous utilisez Express en COMPRENANT ce qu'il fait, au lieu de le subir comme une boîte noire magique. Voici les bénéfices concrets. (1) Démystifier ce qui se passe vraiment. Quand vous écrivez une route Express, que se passe-t-il RÉELLEMENT ? Sans avoir vu le natif, c'est de la magie : vous appelez app.get() et « ça marche ». En ayant créé un serveur natif, vous SAVEZ : une requête HTTP arrive, il y a des objets req et res, il faut router selon la méthode et l'URL, définir un statut et des en-têtes, envoyer un corps. Express automatise tout cela, mais vous comprenez le mécanisme sous-jacent. Cette compréhension transforme votre rapport à l'outil. (2) Comprendre ce qu'Express APPORTE. En ayant galéré à router « à la main » (une cascade de if (req.url === ... && req.method === ...)), à parser le corps d'une requête POST (lire un stream, accumuler les morceaux, parser le JSON), à définir les en-têtes manuellement — vous MESUREZ ce qu'Express simplifie : le routage élégant (app.get('/users', ...)), le parsing automatique du corps (express.json()), les middlewares, etc. Vous appréciez et utilisez Express à bon escient, en sachant quel problème chaque fonctionnalité résout. (3) Mieux déboguer. Quand quelque chose ne va pas dans Express (un en-tête manquant, un statut incorrect, un corps non parsé), comprendre le HTTP natif (req/res, en-têtes, statuts, streams pour le corps) vous aide à diagnostiquer — vous savez ce qui se passe à bas niveau. Un développeur qui ne connaît qu'Express est démuni quand la « magie » échoue. (4) Maîtriser le protocole HTTP. Créer un serveur natif vous force à comprendre HTTP : les méthodes (GET/POST/PUT/DELETE), les codes de statut (200/201/400/404/500), les en-têtes, le corps. Cette connaissance de HTTP est FONDAMENTALE et TRANSVERSALE : elle vaut pour Express, pour tout autre framework, pour les API REST (section 4-1), pour le débogage réseau, pour comprendre le web en général. C'est un socle qui vous servira toute votre carrière, quel que soit le framework. (5) Ne pas dépendre aveuglément d'un framework. Comprendre le natif vous rend moins « prisonnier » d'Express : vous pourriez utiliser un autre framework (Fastify, Koa…), ou le http natif directement pour un cas simple, en comprenant les principes communs. Les frameworks vont et viennent ; la compréhension du HTTP et du modèle req/res reste. Une analogie : c'est comme apprendre à conduire une voiture manuelle avant l'automatique. L'automatique (Express) est plus pratique au quotidien, et vous l'utiliserez. Mais avoir compris l'embrayage et les vitesses (le natif) vous fait comprendre ce que l'automatique fait pour vous, mieux réagir quand ça se passe mal, et être un conducteur plus complet. Beaucoup de développeurs sautent cette étape et utilisent Express sans jamais comprendre le HTTP sous-jacent — ils s'en sortent, mais restent limités (déboguer difficilement, ne pas comprendre les subtilités, être perdus hors d'Express). Prendre le temps du natif (même brièvement) vous met dans une autre catégorie. Est-ce beaucoup de travail ? Non — quelques exemples suffisent : créer un serveur, renvoyer une réponse, router à la main sur deux ou trois routes, renvoyer du JSON. En une session, vous saisissez le modèle req/res et le HTTP, et vous êtes prêt à aborder Express avec une vraie compréhension. Ne sautez pas cette étape sous prétexte qu'« Express fait tout » : c'est justement pour bien utiliser Express (et au-delà) qu'il faut comprendre ce qu'il y a dessous. La compréhension du fondement (HTTP, req/res) est un investissement rentable pour toute votre pratique du web côté serveur. Après cela, vous utiliserez Express avec plaisir ET lucidité.
Quelles sont les bases du protocole HTTP que je dois absolument connaître ?
HTTP est le protocole du web, et le comprendre est FONDAMENTAL pour tout développement serveur (Node, Express, API) — voici les bases essentielles à maîtriser, qui vous serviront constamment. (1) Le modèle requête/réponse. HTTP fonctionne par échanges : un client (navigateur, application, autre serveur) envoie une REQUÊTE, le serveur renvoie une RÉPONSE. C'est le cycle de base de tout le web. Chaque interaction (charger une page, appeler une API) est une requête suivie d'une réponse. (2) Les MÉTHODES HTTP (aussi appelées « verbes ») — elles indiquent l'INTENTION de la requête : GET (LIRE / récupérer une ressource — « donne-moi les utilisateurs »), POST (CRÉER une ressource — « crée cet utilisateur »), PUT (REMPLACER / mettre à jour entièrement), PATCH (mettre à jour PARTIELLEMENT), DELETE (SUPPRIMER). Ces méthodes structurent les API REST (section 4-1) : une même URL (/users) fait des choses différentes selon la méthode (GET liste, POST crée). Connaître ce vocabulaire est indispensable. (3) Les CODES DE STATUT — la réponse porte un code à 3 chiffres indiquant le RÉSULTAT, groupés par familles : 2xx (succès) : 200 OK (succès général), 201 Created (ressource créée, après un POST), 204 No Content (succès sans corps) ; 3xx (redirection) : 301/302 (redirections) ; 4xx (erreur CLIENT) : 400 Bad Request (requête mal formée), 401 Unauthorized (non authentifié), 403 Forbidden (authentifié mais pas autorisé), 404 Not Found (ressource inexistante), 409 Conflict, 422 (validation) ; 5xx (erreur SERVEUR) : 500 Internal Server Error (erreur côté serveur), 503 Service Unavailable. Utiliser les BONS codes est important (une API bien conçue renvoie 201 après création, 404 si non trouvé, 400 si données invalides, 401 si non authentifié — pas 200 pour tout). Cela communique clairement au client ce qui s'est passé. (4) Les EN-TÊTES (headers) — des métadonnées de la requête/réponse : Content-Type (le type du corps : application/json, text/html…), Authorization (les identifiants/jetons d'authentification), Accept (ce que le client accepte), les en-têtes de cache, de CORS, de cookies… Les en-têtes portent beaucoup d'informations importantes (notamment l'authentification et le type de contenu). (5) Le CORPS (body) — les données transportées : dans une requête POST/PUT (les données à créer/modifier, souvent en JSON), dans une réponse (le contenu renvoyé, HTML ou JSON). GET n'a normalement pas de corps de requête. (6) L'URL et les paramètres : le chemin (/users/42), les paramètres de route (42 = l'id), les paramètres de requête (query string : ?page=2&limit=10). (7) Notion : HTTP est sans état (stateless) — chaque requête est indépendante, le serveur ne « se souvient » pas des requêtes précédentes par défaut (d'où les mécanismes d'authentification par jetons/sessions, section 4-2). Pourquoi ces bases sont cruciales : (1) Elles sont le VOCABULAIRE de tout développement web serveur — vous les utilisez à chaque route, chaque API, chaque réponse. (2) Elles structurent les API REST (méthodes + URL + codes de statut). (3) Elles sont indispensables au DÉBOGAGE (comprendre pourquoi une requête échoue : quel code, quels en-têtes, quel corps ?). (4) Elles sont TRANSVERSALES : valables pour Node/Express, mais aussi pour tout autre framework/langage, et pour le front-end (qui fait des requêtes HTTP). C'est un savoir universel du web. En pratique, vous n'avez pas à tout mémoriser d'un coup, mais retenez : le modèle requête/réponse, les méthodes principales (GET/POST/PUT/DELETE), les codes de statut par familles (2xx succès, 4xx erreur client, 5xx erreur serveur, avec les principaux : 200, 201, 400, 401, 404, 500), les en-têtes clés (Content-Type, Authorization), le corps (souvent JSON). Ces bases, vous les manipulerez constamment — elles deviendront une seconde nature. Créer un serveur HTTP natif (cette section) est justement l'occasion de les rencontrer concrètement (définir un statut, un en-tête, lire une méthode/URL). Investir dans la compréhension de HTTP est l'un des meilleurs investissements pour un développeur web : c'est le langage commun de tout le web, côté serveur comme client.