C’est quoi une API REST ? Et pourquoi tous vos outils en parlent
Une API REST est une API web qui applique les principes de l’architecture REST : chaque donnée est une ressource identifiée par une URL, et les verbes HTTP (GET, POST, PUT, DELETE) décrivent l’action à effectuer, sans mémoriser l’historique des requêtes précédentes. C’est devenu le standard de facto du web.
Une API REST organise chaque donnée comme une ressource accessible par une URL, et utilise les verbes HTTP standards pour dire ce qu’on veut en faire.
C’est quoi une API REST exactement ?
REST (Representational State Transfer) n’est pas une technologie mais un style d’architecture : un ensemble de contraintes que respectent la plupart des API web modernes, de Stripe à GitHub en passant par la majorité des CRM.
Trois principes suffisent à reconnaître une API REST au premier coup d’œil.
Chaque donnée (un client, une commande, un article) possède sa propre URL, comme /clients/42.
GET pour lire, POST pour créer, PUT pour modifier, DELETE pour supprimer une ressource.
Chaque requête contient tout ce qu’il faut pour être traitée, sans dépendre d’un échange précédent.
Notre article sur ce qu’est une API pose les bases générales de ces échanges. REST en est aujourd’hui le style dominant, au point que « API » et « API REST » sont souvent utilisés l’un pour l’autre dans les conversations courantes, même si ce n’est techniquement pas synonyme.
À quoi ressemble une requête REST concrètement ?
Prenons un exemple simple : récupérer les informations d’un client dans un CRM qui expose une API REST.
- On identifie la ressourceL’URL
/clients/42désigne précisément le client numéro 42. - On choisit le verbe HTTPGET pour lire, sans rien modifier côté serveur.
- On envoie la requête avec authentificationUne clé d’API prouve que la demande est autorisée.
- Le serveur répond avec un code de statut200 si tout va bien, 404 si la ressource n’existe pas.
- La réponse contient les données en JSONNom, e-mail, historique : uniquement les champs prévus par l’API.
La liste des codes de statut HTTP de MDN permet de comprendre rapidement si une requête a réussi, échoué côté client ou échoué côté serveur, ce qui facilite le débogage d’un workflow d’automatisation.
REST, SOAP ou GraphQL : pourquoi REST domine-t-il ?
REST n’est pas le seul style d’API, mais c’est de loin le plus répandu grâce à sa simplicité et à son appui direct sur le protocole HTTP, déjà maîtrisé par tous les outils du web.
| Critère | REST | GraphQL | SOAP |
|---|---|---|---|
| Format d’échange | JSON, en général | JSON, requêtes typées | XML strict |
| Flexibilité | Un endpoint = une ressource fixe | Le client choisit les champs voulus | Contrat XML rigide (WSDL) |
| Courbe d’apprentissage | Faible, s’appuie sur HTTP connu | Moyenne, langage à apprendre | Élevée, verbeux et normé |
| Où on le rencontre | La majorité des API publiques actuelles | Applications aux besoins de données complexes | Systèmes bancaires ou legacy normés |
Pour une TPE/PME qui connecte des outils entre eux avec n8n ou Make, REST reste le choix par défaut : la quasi-totalité des services grand public l’exposent nativement.
Quels sont des exemples d’API REST au quotidien ?
Sans forcément le savoir, vous interagissez déjà avec plusieurs API REST chaque semaine.
L’API REST de Stripe
Chaque client, paiement ou abonnement est une ressource accessible par son propre identifiant.
L’API REST de GitHub
Dépôts, commits et pull requests sont tous exposés comme des ressources REST documentées.
L’API de votre CRM
Créer, lire ou mettre à jour une fiche contact via des appels GET, POST et PUT classiques.
Une API météo publique
Interroger une ville par son identifiant et recevoir les prévisions en JSON.
Dans un workflow n8n, chacun de ces appels REST se configure dans un même bloc HTTP Request, quel que soit le service interrogé.
Comment lisons-nous une API REST chez Amari Agency ?
Voici un exemple représentatif de notre méthode, sans donnée client ni chiffre inventé.
La documentation avant le premier appel
Avant de connecter une nouvelle API REST dans n8n, nous repérons ses ressources principales et les verbes disponibles pour chacune, puis nous testons un appel de lecture seule (GET) avant tout appel qui modifie une donnée. Les réponses JSON sont ensuite stockées dans Supabase pour être réutilisées dans d’autres étapes du workflow.
Cette lecture méthodique évite les mauvaises surprises : un verbe DELETE mal utilisé sur la mauvaise ressource peut avoir des conséquences bien plus lourdes qu’une simple erreur de lecture.
Quels sont les bénéfices et les limites de REST ?
REST doit sa popularité à sa simplicité, mais ce choix implique aussi certains compromis à connaître avant de construire une automatisation dessus.
Ce que REST apporte
- S’appuie sur HTTP, déjà connu de tous les outils du web.
- Largement documenté et enseigné.
- Compatible avec la quasi-totalité des outils no-code.
- Mise en cache facile pour les requêtes de lecture (GET).
Ce qu’il faut anticiper
- Plusieurs appels parfois nécessaires pour rassembler des données liées.
- Pas de contrat aussi strict que SOAP.
- La structure des réponses peut évoluer selon les versions.
- Risque de sur-récupérer des champs inutiles à chaque appel.
Pour la grande majorité des automatisations d’une TPE/PME, ces limites restent mineures face à la simplicité de mise en œuvre que REST permet.
Comment lire une documentation d’API REST ?
Chaque documentation REST sérieuse suit une structure proche, ce qui accélère la prise en main d’un nouvel outil.
/clients, /commandes) indiquent les ressources disponibles.Si vous préférez déléguer ces connexions, découvrez nos solutions d’automatisation IA sur mesure. Pour apprendre à manipuler ces API vous-même, notre formation IA générative certifiante couvre les connexions entre outils, avec des financements possibles selon votre statut.
Quels contenus lire ensuite ?
Ces ressources complètent la définition sans cibler la même requête :
Questions fréquentes sur les API REST
Toutes les API sont-elles des API REST ?
Non. REST est le style le plus répandu, mais il existe aussi SOAP, GraphQL ou des API propriétaires qui ne suivent pas ces principes. Il faut vérifier la documentation de chaque service pour le confirmer.
Que signifie concrètement « sans état » (stateless) ?
Cela veut dire que le serveur ne conserve aucune mémoire des requêtes précédentes. Chaque appel doit contenir toutes les informations nécessaires (identifiant, authentification) pour être traité indépendamment.
Pourquoi les URL des API REST utilisent-elles souvent le pluriel ?
Par convention, /clients désigne l’ensemble des clients et /clients/42 un client précis. Cette cohérence facilite la lecture de la documentation d’une API à l’autre.
Une API REST renvoie-t-elle toujours du JSON ?
Le JSON est très majoritaire aujourd’hui, mais REST n’impose pas de format précis. Certaines API REST plus anciennes utilisent encore le XML.
Faut-il toujours préférer REST à GraphQL ?
Pas systématiquement. REST convient à la majorité des besoins simples, tandis que GraphQL peut être plus adapté quand une application doit assembler des données complexes provenant de plusieurs ressources en un seul appel.