API REST
Définition
Style d'API basé sur des URL pour des ressources (GET, POST, PUT, DELETE). Le plus courant pour exposer un backend à un frontend ou à un partenaire.
Comment ça marche
Une API REST expose des ressources accessibles par URL via des verbes HTTP : GET pour lire, POST pour créer, PUT ou PATCH pour modifier, DELETE pour supprimer. Le format d'échange est généralement du JSON, l'authentification se fait par token (JWT) ou clé API dans les en-têtes. Chaque ressource a une URL prévisible : /articles, /articles/123, /articles/123/comments. Les codes de statut HTTP indiquent le résultat : 200 pour un succès, 401 pour un défaut d'authentification, 404 pour une ressource introuvable, 422 pour une erreur de validation, 500 pour une erreur serveur.
À quoi ça sert
REST est le style le plus répandu pour exposer un backend à un frontend, à une app mobile, à un partenaire ou à des intégrations tierces. Simple, bien documenté, lisible dans n'importe quel outil HTTP (Postman, Insomnia, curl, navigateur), il reste le choix par défaut sur la majorité des projets web modernes. Tous les langages serveurs proposent des frameworks adaptés (Next.js route handlers, Express, FastAPI, Rails). Tous les clients (navigateur, mobile, embarqué) savent l'appeler nativement. C'est l'interface universelle du web depuis vingt ans.
Les conventions importantes
Une API REST propre suit quelques conventions : URL au pluriel pour les collections (/users, pas /user), verbe HTTP cohérent avec l'action, paramètres de filtre en query string (?status=active), pagination via cursor ou page/limit, réponses uniformes (data, error, meta), versionnage via préfixe d'URL (/v1, /v2) ou en-tête. On documente l'API avec OpenAPI (anciennement Swagger), ce qui génère automatiquement de la doc, des SDK clients et des tests. Sans documentation, une API REST devient vite illisible pour les consommateurs externes.
Sécurité et authentification
Une API REST publique doit gérer l'authentification (qui est l'appelant), l'autorisation (a-t-il le droit de faire cette action), la validation (les arguments sont-ils conformes), le rate limiting (limiter les abus), et les CORS si appelée depuis un navigateur. JWT, OAuth2 et clés API sont les mécanismes courants selon le contexte. On valide les entrées avec un schéma (Zod, Joi, Pydantic) avant tout traitement. On ne fait jamais confiance au client, même quand on l'a écrit nous-même : une faille ne dépend que de l'attaquant, pas de la confiance qu'on porte au consommateur.
Les limites de REST
REST montre ses limites quand le client a besoin de récupérer beaucoup de données reliées en une seule requête, ou de choisir précisément les champs renvoyés. Le over-fetching (recevoir trop de données inutiles) et le under-fetching (devoir faire plusieurs appels pour reconstituer une vue) plombent les performances mobiles. Sur des UI complexes type dashboard ou réseau social, on enchaîne parfois cinq ou six appels REST pour construire une seule page. Dans ces cas, on regarde GraphQL, des endpoints BFF dédiés à la vue, ou un agrégateur côté serveur.
REST versus alternatives
Face à GraphQL, REST reste plus simple à mettre en place, à debugger, à cacher au niveau HTTP. GraphQL gagne sur les UI très agrégées et sur le typage de bout en bout. Face à tRPC ou Server Actions, REST gagne quand l'API doit servir des clients hétérogènes ou être consommée par des partenaires. Face à gRPC, REST gagne en accessibilité et en outillage, gRPC gagne en performance pour les communications service-à-service. Pour la majorité des projets web B2B, REST avec OpenAPI reste le bon défaut, modulo quelques exceptions ciblées.