Front web + mobile
Un seul back-end alimente plusieurs clients.
Qu'est-ce qu'une API REST ? Ressources, verbes HTTP et contrats
Une API REST est une interface web qui expose des ressources via HTTP, en utilisant des URL stables, des verbes (GET, POST, PUT, PATCH, DELETE) et des représentations souvent JSON. Inspirée du style architectural de Roy Fielding, elle privilégie la statelessness côté serveur et une sémantique HTTP claire. C'est le contrat le plus courant entre un front, une app mobile et un back-end métier.
En une phrase
Une API REST fait parler clients et serveurs via HTTP et des ressources adressables.
À retenir
- Les ressources ont des URI ; les verbes HTTP décrivent l'action sans inventer un protocole parallèle.
- Le serveur ne conserve pas l'état de session entre requêtes (stateless) : chaque appel porte le contexte nécessaire.
- JSON domine pour les payloads ; les codes de statut (2xx, 4xx, 5xx) communiquent le résultat.
- OpenAPI/Swagger documente le contrat pour les équipes front, mobile et partenaires.
Fiche du terme
- API REST
- REST API · API RESTful · Web API REST
- Terme anglais
- REST API
- Domaine
- Développement
- Catégorie
- Intégration
- Niveau
- Intermédiaire
Que signifie exactement « API REST » ?
REST (Representational State Transfer) n'est pas un standard ISO unique mais un style : identification des ressources, manipulation via représentations, messages auto-descriptifs et, idéalement, hypermedia. En pratique, « API REST » désigne souvent une API HTTP JSON bien structurée, même si toutes les contraintes Fielding ne sont pas strictement suivies.
Pour une PME, l'API REST est la charnière entre le site, l'app mobile, un ERP ou un partenaire. Un mauvais design (verbes dans l'URL, sessions collantes, erreurs opaques) ralentit chaque intégration et augmente le coût de support.
La sécurité (TLS, OAuth 2.0 / JWT, rate limiting) et la versioning (/v1) font partie du produit API autant que les endpoints métier.
Comment conçoit-on une API REST solide ?
- 01
Modéliser les ressources
Nommer les entités métier (clients, commandes, factures) et leurs relations plutôt que des actions RPC dispersées.
- 02
Fixer le contrat
Schémas de requête/réponse, codes d'erreur, pagination et filtres — idéalement décrits en OpenAPI.
- 03
Sécuriser et observer
Authentification, autorisation fine, journaux, métriques de latence et quotas.
- 04
Versionner et évoluer
Évolutions rétrocompatibles d'abord ; breaking changes derrière une nouvelle version majeure.
Exemple concret d'API REST
Un manufacturier montréalais expose GET /v1/orders/{id} et PATCH /v1/orders/{id}/status pour que son portail client et l'app des livreurs lisent et mettent à jour le même état. Les réponses JSON incluent un ETag ; le client mobile évite de recharger toute la commande si rien n'a changé. Le support voit chuter les « où en est ma commande ? » traités manuellement.
À quoi sert une API REST ?
Intégrations partenaires
Échange de catalogues, stocks ou leads avec des systèmes tiers.
Automatisation interne
Scripts et outils métier consomment les mêmes endpoints que le produit.
Microservices
Communication synchrone entre services via HTTP JSON.
Avantages et limites des API REST
- Écosystème HTTP mature (caches, proxies, outils)
- Lisibilité des URI et des verbes pour les équipes
- Large support clients (navigateurs, mobiles, SDK)
- Documentation et tests facilités (OpenAPI, Postman)
- Sur-fetch / under-fetch si les ressources sont mal découpées
- Moins adapté au temps réel que WebSocket ou gRPC streaming
- Versioning et compatibilité demandent de la discipline
- « REST-washing » : beaucoup d'API HTTP ne respectent pas vraiment REST
Quelle différence entre API REST et GraphQL ?
| API REST | GraphQL | |
|---|---|---|
| Forme de la requête | Plusieurs endpoints ressources + verbes HTTP | Un endpoint ; le client décrit les champs voulus |
| Cache HTTP | Naturel sur GET (URI, ETag) | Plus complexe ; souvent cache applicatif |
| Courbe d'apprentissage | Faible si on connaît HTTP | Schéma, resolvers, outils dédiés |
| Cas idéal | Contrats stables, intégrations classiques | Clients avec besoins de données très variables |
Pourquoi une API REST compte pour une PME québécoise ?
Dès qu'un site, une app ou un partenaire doit lire votre stock, vos rendez-vous ou vos clients, vous avez besoin d'un contrat stable. Une API REST claire réduit le coût de chaque intégration, accélère les partenariats et évite de reconstruire la même logique dans chaque canal.
Questions fréquentes
REST est-il un protocole ?
Non. C'est un style architectural au-dessus d'HTTP. On parle d'API REST lorsqu'on applique (plus ou moins strictement) ses contraintes.
Faut-il toujours du JSON ?
JSON est le défaut de facto, mais REST autorise d'autres représentations (XML, etc.) via la négociation de contenu.
Comment versionner sans casser les clients ?
Préférez les ajouts rétrocompatibles ; réservez /v2 aux breaking changes et communiquez une date de fin de support.
REST remplace-t-il les files de messages ?
Non. REST convient aux requêtes synchrone requête/réponse ; les files (ou events) restent utiles pour le découplage asynchrone.
Termes associés
Sources et références
Vous devez exposer vos données à un site, une app ou un partenaire ? Nous concevons des API REST documentées, sécurisées et évolutives.
Parler de votre API