Une API REST est une interface de programmation qui suit les principes du style architectural REST. Elle permet à des applications de communiquer autour de ressources, par exemple des utilisateurs, des articles ou des commandes, via des requêtes et des réponses structurées.
Dans un écosystème de logiciels d’automatisation clés, une API REST sert souvent à lire, créer ou mettre à jour des données entre deux services.
Mécanisme général
Red Hat rappelle que REST est un ensemble de contraintes architecturales, pas un protocole ni un standard unique. En pratique, beaucoup d’API REST utilisent HTTP, des méthodes comme GET ou POST, des URL qui représentent des ressources et des formats de réponse comme JSON.
Une requête contient généralement une méthode, une URL, des paramètres éventuels, des en-têtes et parfois un corps. La réponse contient un statut HTTP, des en-têtes et une représentation de la ressource ou du résultat demandé.
Les contraintes qui distinguent REST
Sans état de session côté serveur signifie que chaque requête apporte les informations nécessaires à son traitement. Cela n’interdit pas au serveur de conserver des articles ou des comptes dans une base : les données métier et l’état de conversation du client sont deux choses différentes.
REST prévoit aussi une séparation client-serveur, une interface uniforme, des réponses dont les règles de cache sont explicites et un système en couches. L’interface uniforme comprend des ressources identifiables, des messages auto-descriptifs et des liens permettant de découvrir les actions possibles. Une simple URL qui renvoie du JSON ne suffit donc pas à démontrer que toutes les contraintes sont respectées.
Exemple illustratif
Exemple pédagogique : GET /articles/42 peut représenter la lecture de l’article fictif numéro 42. POST /articles peut représenter la création d’un article à partir d’un corps JSON. Ces exemples ne décrivent pas une API réelle ; ils montrent seulement la logique ressource plus méthode.
À ne pas confondre
- REST et JSON : JSON est courant, mais REST ne signifie pas JSON obligatoire.
- REST et toute API HTTP : une API peut utiliser HTTP sans respecter clairement les contraintes REST.
- API et webhook : l’API est souvent appelée par un client ; le webhook envoie une notification à votre serveur.
Limites et sécurité
Une API REST mal protégée expose vite trop de données. Il faut gérer l’authentification, les autorisations, la validation des entrées, les quotas, les erreurs et les journaux. Les en-têtes et paramètres peuvent contenir des informations sensibles : ne les copiez pas dans un ticket public ou un article.
REST ne règle pas non plus la cohérence métier. Deux appels répétés peuvent créer deux ressources si l’API n’est pas idempotente. Pour les actions critiques, documentez clairement les méthodes sûres, les codes d’erreur et les identifiants de requête.
Usage associé
Dans n8n ou un autre outil, une API REST est utile pour enrichir un workflow : récupérer une fiche client, créer une tâche ou envoyer un statut. Avant d’automatiser, lisez la documentation de l’API cible et testez avec des données fictives.
Quand l’utiliser dans un projet
Une API REST est adaptée quand un service doit exposer des ressources de manière relativement prévisible : clients, articles, produits, tickets, factures ou événements. Elle est lisible pour les développeurs, facile à tester avec des outils HTTP et compatible avec beaucoup de plateformes no-code ou low-code.
Avant d’automatiser une API REST, clarifiez trois points : quelle ressource est manipulée, quelle méthode est autorisée et quel résultat doit être considéré comme réussi. Un statut 200 ou 201 ne suffit pas toujours à valider le métier : vérifiez aussi le corps de réponse, l’identifiant retourné et les règles en cas d’appel répété. Pour les données sensibles, préférez des permissions minimales à une clé globale trop puissante.
Pour documenter une API REST, notez aussi les statuts attendus : lecture réussie, création acceptée, ressource absente, authentification refusée et limite dépassée. Cette carte d’erreurs évite de construire une automatisation qui casse au premier cas non nominal.
Pour aller plus loin
Le guide Webhook n8n et premier POST illustre la réception d’une requête HTTP, sans constituer à lui seul une API respectant toutes les contraintes REST. La fiche webhook explique le déclenchement par événement.
Retrouvez les autres notions dans le lexique IA et automatisation de Gridpak.
