Une API REST (*Representational State Transfer*) est une interface web où chaque donnée est exposée comme une ressource identifiée par une URL (`/clients/123`, `/factures/2026-001`), et manipulée via les verbes HTTP standards : `GET` pour lire, `POST` pour créer, `PUT`/`PATCH` pour modifier, `DELETE` pour supprimer. Le format d'échange est presque toujours JSON. Conceptualisé par Roy Fielding en 2000, REST a écrasé les anciens standards (SOAP, RPC, XML-RPC) parce qu'il est simple, sans état, cacheable nativement par HTTP, et compréhensible avec un simple `curl` ou un onglet réseau du navigateur.
REST est devenu le standard de fait pour exposer un SaaS, un CRM, un ERP, ou n'importe quel logiciel métier — Stripe, GitHub, Slack, HubSpot, Salesforce ont tous une API REST. Côté client, n'importe quel langage sait faire un appel HTTP, donc l'intégration est triviale. Côté serveur, le découplage permet à plusieurs équipes (web, mobile, partenaires) de consommer la même donnée. Pour les architectures internes complexes avec beaucoup de relations entre entités, GraphQL prend des parts de marché — mais REST reste le défaut raisonnable pour 80 % des cas.
Une bonne API REST tient à 4 choses : versioning (`/v1/`, `/v2/`) pour ne pas casser les clients existants, authentification propre (OAuth 2.0, JWT, clés API scopées), pagination/filtering documentés, et codes HTTP corrects (200, 201, 400, 401, 403, 404, 422, 500 — pas tout en 200 avec un `error: true` planqué). Pour les notifications d'événements, on complète l'API REST avec des webhooks push plutôt que du polling. C'est l'archi standard d'un logiciel sur-mesure moderne, déployé sur du cloud en microservices ou en monolithe modulaire.
API REST : ce qui distingue une bonne d'une mauvaise
- Verbes HTTP corrects : `POST` ne lit pas, `GET` ne modifie pas — c'est la base, c'est souvent raté.
- Codes de statut justes : 401 ≠ 403, 422 ≠ 400 — un bon code permet au client de gérer les erreurs proprement.
- Versioning explicite dès la v1 : `/api/v1/clients` — sinon vous serez bloqué pour toute évolution breaking.
- Documentation OpenAPI/Swagger générée depuis le code, pas écrite à part qui finit obsolète en 3 mois.
