API REST et interopérabilité : les principes qui relient les applications
Dans une entreprise technologique, un site marchand, une application mobile et un logiciel de gestion doivent souvent accéder aux mêmes informations. Une API REST organise ces échanges au moyen de ressources identifiées par des URI et de requêtes fondées sur les protocoles HTTP.
REST est un style architectural, et non un protocole indépendant. Roy Fielding l’a formalisé dans sa thèse de 2000 ; ses principes favorisent notamment la séparation entre client et serveur, ainsi que des échanges sans état de session conservé côté serveur.
Des ressources clairement identifiées
Pour une plateforme de vente, une ressource peut représenter un produit, une commande ou un client. Des adresses comme /products et /orders/42 rendent ces objets accessibles sans inscrire l’action dans leur nom.
Cette convention facilite l’intégration applicative : le navigateur, l’application mobile et le système logistique peuvent solliciter le même service. Chaque client conserve son interface, tandis que le serveur gère les règles métier et les données.
Conventions utiles pour les URI :
- Des noms de ressources explicites et généralement au pluriel
- Un identifiant stable pour accéder à un élément précis
- Des paramètres de requête pour filtrer ou trier une collection
- Des verbes HTTP pour indiquer l’opération attendue
Une représentation commune des données
Le serveur transmet une représentation de la ressource, le plus souvent dans des formats JSON. Les en-têtes HTTP précisent le type de contenu et le format attendu, ce qui aide des applications développées avec des technologies différentes à interpréter les réponses.
Selon Roy Fielding, l’interface uniforme constitue un principe central de REST. Elle rend les échanges plus prévisibles, mais la qualité de l’interopérabilité dépend aussi de conventions documentées et de modèles de données compris par les équipes.