API Versioning

Architecture 🟡 Mid

Définition

Stratégies pour faire évoluer une API sans casser les clients existants : URL path (/v1/), header (Accept), query param. Chaque approche a ses tradeoffs.

Analogie

Les éditions d'un manuel scolaire : la v1 reste disponible pendant que la v2 est utilisée par les nouveaux étudiants.

Exemple de code

// URL versioning (le plus courant)
app.use('/api/v1/users', usersV1Router);
app.use('/api/v2/users', usersV2Router);
// Header versioning
// Accept: application/vnd.api+json;version=2

Cas d'usage

APIs publiques avec des clients que vous ne contrôlez pas et qui ne migrent pas en même temps.

Anti-pattern

Breaking changes sans versioning — les clients en production cassent.
#architecture#interview#api#best-practice

En entretien

  1. Quelles stratégies existent pour versionner une API ?

    Trois approches courantes : versioning par URL path (/v1/), par header (Accept) ou par query param, chacune avec ses tradeoffs.

  2. Pourquoi versionner une API publique est important ?

    Parce que les clients que tu ne contrôles pas ne migrent pas tous en même temps ; sans versioning, un breaking change casse les clients déjà en production.

Fiche mise à jour le 2026-09-27

← → au clavier pour passer d'une fiche à l'autre