Comment créer une API REST simplement pour son projet

La question revient à chaque fois qu'un développeur solo attaque un nouveau projet : « j'ai vraiment besoin d'une API REST, ou je peux juste me débrouiller autrement ? »

Et honnêtement, dans la moitié des cas que je vois passer, la réponse est non. Pas besoin d'API. Une route serveur bien posée suffit. Mais dans l'autre moitié, la personne se lance dans un chantier de trois semaines avec Docker, une base Postgres et une architecture en couches, alors qu'elle voulait juste qu'un formulaire parle à sa base de données.

Créer une API REST simplement pour son projet, ce n'est pas un problème technique. C'est un problème de dosage. Vous prenez trop, vous abandonnez au bout de dix jours. Vous prenez trop peu, vous vous retrouvez coincé dans six mois quand vous voudrez ajouter une appli mobile.

Je vais vous montrer les deux erreurs, comment choisir votre stack selon la taille réelle de votre projet, et un exemple de code complet d'un endpoint CRUD que vous pouvez coller tel quel dans un dossier vide.

Créer une API REST simplement : d'abord, vérifiez qu'elle sert à quelque chose

Une API REST, c'est un ensemble de routes HTTP qui exposent vos données en JSON, avec des conventions stables : GET pour lire, POST pour créer, PUT ou PATCH pour modifier, DELETE pour supprimer. Rien de plus mystérieux.

Le déclencheur, dans mon expérience, c'est presque toujours le même : vous avez écrit votre site avec le front et le back mélangés, et un jour vous voulez afficher les mêmes données dans une appli mobile. Là, vous réalisez que toute votre logique est coincée dans des templates serveur.

Avant de vous lancer, posez-vous une seule question : est-ce que plus d'un client va consommer ces données ?

Quand une API devient réellement nécessaire

• Un site web et une appli mobile pointent vers les mêmes enregistrements.
• Un script d'import tourne la nuit et doit écrire dans la base sans passer par l'interface web.
• Vous voulez séparer le front (React, Vue) du back parce que vous changez de framework tous les dix-huit mois.
• Une intégration tierce (Stripe, un webhook) doit notifier votre application d'un événement.

Quand vous pouvez vous en passer sans culpabiliser

Un blog personnel avec un seul auteur. Un outil interne que vous êtes seul à utiliser depuis un navigateur. Un prototype dont vous ne savez pas encore s'il vivra plus de deux mois.

Dans ces cas-là, une route serveur classique qui rend du HTML fait le travail, et vous économisez la gestion du CORS, l'authentification par token et toute la plomberie JSON. J'ai vu des gens monter une API complète pour un projet qui n'a jamais dépassé dix utilisateurs. C'est du temps perdu, et surtout du temps qui aurait pu servir à parler à ces dix utilisateurs.

Choisir son stack quand on est seul sur le projet

Voici la partie qui manque dans la plupart des tutos : ils vous montrent comment coder une API, jamais pourquoi choisir tel outil plutôt que tel autre.

Pour un projet solo, le critère n'est pas la performance brute ni l'élégance architecturale. C'est le temps entre « je commence » et « ça répond ».

Stack	Langage	Mise en route	Idéal pour
Express	JavaScript / Node	~15 min	Vous connaissez déjà JS côté front
FastAPI	Python	~20 min	Validation automatique et doc générée
Flask	Python	~10 min	Un endpoint, une base, rien d'autre
NestJS	TypeScript	~1 h	Projet qui va grossir et durer
Laravel	PHP	~30 min	Vous venez du monde PHP et de l'hébergement mutualisé

Si vous hésitez encore, prenez le langage dans lequel vous êtes déjà à l'aise. Le meilleur framework est celui que vous n'aurez pas à apprendre en même temps que le concept d'API REST.

Express ou FastAPI : comment trancher

Express vous laisse tout faire à la main. C'est un avantage quand vous savez ce que vous faites, un piège quand vous débutez : aucune structure imposée, donc vous pouvez accumuler de la dette sans vous en rendre compte.

FastAPI fait l'inverse. Il vous impose de déclarer les types de vos données, génère la documentation tout seul et valide les entrées automatiquement. Sur mon dernier projet Python, cette validation m'a fait gagner un temps fou : je n'ai plus eu à écrire une seule ligne pour vérifier qu'un champ était bien un entier.

Verdict personnel : FastAPI si vous partez de zéro en Python, Express si vous êtes déjà à l'aise en JavaScript. Ne mélangez pas les deux apprentissages.

Un exemple complet : un endpoint CRUD minimal

Voici une API REST fonctionnelle, avec une seule ressource, en Node et Express. Elle tient dans un fichier, utilise une base de données fichier et répond en JSON.

import express from 'express';
import Database from 'better-sqlite3';

const app = express();
const db = new Database('data.db');

app.use(express.json());

db.exec(`CREATE TABLE IF NOT EXISTS taches (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  titre TEXT NOT NULL,
  faite INTEGER DEFAULT 0
)`);

app.get('/taches', (req, res) => {
  res.json(db.prepare('SELECT * FROM taches').all());
});

app.post('/taches', (req, res) => {
  const { titre } = req.body;
  if (!titre) return res.status(400).json({ erreur: 'titre requis' });
  const info = db.prepare('INSERT INTO taches (titre) VALUES (?)').run(titre);
  res.status(201).json({ id: info.lastInsertRowid, titre, faite: 0 });
});

app.patch('/taches/:id', (req, res) => {
  const { faite } = req.body;
  db.prepare('UPDATE taches SET faite = ? WHERE id = ?').run(faite ? 1 : 0, req.params.id);
  res.status(204).end();
});

app.delete('/taches/:id', (req, res) => {
  db.prepare('DELETE FROM taches WHERE id = ?').run(req.params.id);
  res.status(204).end();
});

app.listen(3000, () => console.log('API sur http://localhost:3000'));

Voilà. Quatre routes, une table, une base SQLite dans un fichier. C'est tout ce dont un projet personnel a besoin pour démarrer. Pas de couche service, pas de dépôt abstrait, pas de conteneur.

Et là, la remarque que je vois arriver : « et si plus tard je veux passer à Postgres ? » Vous le ferez quand vous en aurez besoin. Le code de migration prendra une après-midi, et vous serez content d'avoir livré votre version 1 trois semaines plus tôt.

Convention de nommage : les règles qui tiennent en trois lignes

Les ressources se nomment au pluriel, en minuscules, avec des tirets si besoin. /taches, /utilisateurs, /commandes-client. Jamais de verbe dans l'URL : c'est le verbe HTTP qui porte l'action.

• Bon : GET /taches, POST /taches
• À éviter : GET /getTaches, POST /creerTache
• Une ressource liée se lit en cascade : GET /projets/42/taches

Ces trois conventions couvrent 95 % des cas. Le reste se règle au fil de l'eau, sans avoir besoin d'un document de référence de trente pages.

Les pièges qui font perdre une soirée entière

Trois erreurs reviennent chez presque tous ceux qui posent leur première API. Je les ai toutes commises.

Le CORS bloque vos requêtes du navigateur

Vous testez avec curl, tout fonctionne. Vous appelez l'API depuis votre page web, et là le navigateur refuse. C'est la politique de même origine : par défaut, il n'autorise pas une page servie depuis un domaine à interroger un autre domaine.

La solution tient en une ligne avec le middleware CORS d'Express. En développement, autorisez tout. En production, restreignez à votre domaine réel. C'est tout. Ce n'est pas un problème de sécurité majeur, c'est une formalité que tout le monde oublie la première fois.

Vos erreurs partent en HTML

Une requête invalide, et votre serveur renvoie une page HTML d'exception. Votre client, qui attend du JSON, plante avec un message obscur.

Prévoyez un gestionnaire d'erreurs central qui renvoie toujours du JSON avec un code de statut correct. 400 pour une entrée invalide, 404 pour une ressource absente, 500 pour une erreur interne. Sans ça, vous passerez des heures à déboguer côté front des problèmes qui viennent du back.

Les secrets écrits en clair dans le code

Vous mettez votre clé d'API Stripe en dur dans le fichier. Vous poussez sur GitHub. Vous ne vous en apercevez que le lendemain, quand la clé a déjà été utilisée par quelqu'un d'autre.

Utilisez un fichier .env et la bibliothèque dotenv dès la première ligne de code. Ce n'est pas de la sur-ingénierie, c'est la seule chose que je vous demande vraiment de ne pas négliger.

Déployer sans payer

Pour héberger une petite API, plusieurs plateformes proposent un palier gratuit suffisant : Render, Railway, Fly.io. Le point d'attention, c'est le démarrage à froid : votre API s'endort après quelques minutes d'inactivité et met plusieurs secondes à répondre à la première requête.

Pour un projet personnel, c'est un compromis acceptable. Pour un service que des gens utilisent tous les jours, prévoyez de passer sur une offre payante ou un petit serveur dédié à quelques euros par mois.

Faut-il vraiment une API REST, ou un service tiers suffit-il ?

Une question que l'on me pose souvent, et qui mérite une réponse franche : si votre projet se résume à stocker des données et gérer des utilisateurs, un backend-as-a-service fera le travail mieux et plus vite qu'une API maison.

Supabase vous donne une base Postgres avec une API REST générée automatiquement, l'authentification, et un système de permissions. Firebase propose l'équivalent côté Google. Vous branchez votre front dessus et vous n'écrivez aucune route.

La contrepartie, c'est la dépendance. Vous héritez de leurs limites, de leur modèle de facturation et de leurs pannes. J'ai vu un projet migrer en urgence parce que le fournisseur avait changé son palier gratuit du jour au lendemain.

Mon avis : une API maison commence à valoir le coup dès que vous avez une logique métier un peu spécifique (règles de calcul, intégration avec trois services, permissions fines). En dessous, un BaaS est souvent le choix raisonnable, même si c'est moins satisfaisant intellectuellement.

Et après, on ajoute quoi ?

Vous avez une API qui répond, une base qui persiste et un déploiement en ligne. La tentation, à ce stade, c'est d'empiler tout ce qu'on entend partout : conteneurs, pipeline d'intégration continue, tests end-to-end, observabilité.

Résistez. Ajoutez une chose à la fois, seulement quand un problème réel vous y pousse. Un token d'authentification quand un utilisateur non prévu accède à une donnée. Des tests quand une régression vous a coûté une soirée. Un cache quand une page met trois secondes à charger.

La simplicité au démarrage n'est pas un aveu de faiblesse. C'est ce qui vous permet d'atteindre la version 2. Et la plupart des projets qui échouent ne meurent pas d'une architecture trop légère : ils meurent parce que personne ne les a jamais terminés.