HTTP et les APIs

Quand tu cliques sur "Publier" dans une appli, ton navigateur envoie quelques lignes de texte à un serveur. Le serveur répond avec quelques lignes de texte. C'est tout : HTTP n'a rien de magique. C'est une convention entre deux machines pour se comprendre.

HTTP, un protocole texte

Une requête HTTP ressemble à ça, dans sa forme brute :

POST /api/posts HTTP/1.1
Host: mon-app.com
Content-Type: application/json

{"title": "Mon article", "content": "Bonjour le monde"}

Quatre éléments : la ligne de départ (verbe + chemin + version), les headers (métadonnées : format, authentification, cookies…), une ligne vide qui sépare les headers du corps, et le body (les données, souvent en JSON).

La réponse suit le même schéma :

HTTP/1.1 201 Created
Content-Type: application/json

{"id": 42, "title": "Mon article", "createdAt": "2026-05-25T10:00:00Z"}

Un code de statut, des headers, et un body. Tout le reste (frameworks, ORMs, clouds) n'est que de la plomberie par-dessus ce format texte.

Les 5 verbes essentiels

Le verbe HTTP indique l'intention de l'appelant. Cinq verbes couvrent la quasi-totalité des cas :

GET /api/posts/42 HTTP/1.1
Host: mon-app.com

Les status codes à retenir

Le code de statut est la première chose que tu lis dans une réponse. Il te dit si la requête a abouti, et qui est responsable si ça a raté.

JSON, la langue commune des APIs

La plupart des APIs modernes échangent du JSON (JavaScript Object Notation). C'est du texte structuré que tous les langages savent lire et écrire.

Trois structures de base suffisent à tout représenter :

{
  "id": 42,
  "title": "Mon article",
  "published": true,
  "tags": ["http", "api", "web"],
  "author": {
    "name": "Vicente",
    "email": "contact@blokby.fr"
  }
}

• Objet : paires "clé": valeur entre accolades.
• Tableau : liste de valeurs entre crochets.
• Types primitifs : string (entre guillemets doubles), number, boolean (true/false), null.

Les headers Content-Type: application/json et Accept: application/json indiquent à l'API que tu parles ce dialecte. Sans eux, certains serveurs refusent la requête ou répondent en HTML.

Une API REST en pratique

REST (Representational State Transfer) n'est pas un standard strict : c'est un style architectural. Une API REST organise ses endpoints autour de ressources (/posts, /users, /comments) et utilise les verbes HTTP pour indiquer l'action.

Voici le cycle complet d'une création d'article :

L'API est un contrat : elle définit les URLs, les verbes attendus, les formats de body, et les codes de retour. Le frontend et le backend peuvent évoluer indépendamment tant que le contrat est respecté.

REST, GraphQL, RPC : les trois styles

Pour un débutant, commence par REST : c'est ce que la quasi-totalité des APIs publiques exposent (GitHub, Stripe, Supabase, Vercel…). Tu rencontreras GraphQL dans des frontends complexes et tRPC dans des monorepos Next.js full-TypeScript.

Appeler une API avec fetch

Depuis le navigateur (ou Node.js), fetch est l'outil natif pour envoyer des requêtes HTTP.

// GET : récupérer un article
const response = await fetch('/api/posts/42');
const post = await response.json();
console.log(post.title);

// POST : créer un article
const response = await fetch('/api/posts', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ title: 'Mon article', content: 'Bonjour le monde' }),
});

if (response.status === 201) {
  const newPost = await response.json();
  console.log("Créé avec l'id :", newPost.id);
}

Points importants :

• fetch renvoie une Promise : utilise await ou .then().
• response.ok est true si le code est entre 200 et 299. Vérifie-le avant de parser le body.
• response.json() parse le body JSON. C'est aussi une Promise.

CORS, en un paragraphe

Si ton frontend sur app.exemple.com appelle une API sur api.exemple.com, le navigateur bloque la requête par défaut. C'est la politique d'origine croisée (Same-Origin Policy). Pour autoriser l'appel, le serveur doit renvoyer un header Access-Control-Allow-Origin avec le domaine autorisé (ou * pour tous). Cette protection existe pour empêcher un site malveillant de faire des requêtes à ton API bancaire en utilisant ta session ouverte. En développement local, tu verras souvent des erreurs CORS quand ton frontend sur localhost:3000 tente d'appeler un backend sur localhost:8000 : il faut configurer le serveur pour autoriser l'origine http://localhost:3000.