Dans le développement web moderne, les APIs sont partout. Derrière chaque application mobile, chaque service en ligne ou chaque intégration entre plateformes, une API orchestre silencieusement les échanges de données. Mais la APIs définition ne se résume pas à un simple concept technique : comprendre ce que sont ces interfaces, et surtout distinguer les différents types qui existent, change radicalement la façon d’aborder un projet web. REST, SOAP et GraphQL répondent à des besoins différents, avec des philosophies distinctes. Voici ce qu’il faut savoir pour choisir la bonne approche selon le contexte.
Ce que signifie vraiment une API
Une API (Application Programming Interface) est un ensemble de règles et de protocoles permettant à différentes applications de communiquer entre elles. Concrètement, c’est un intermédiaire qui définit comment un logiciel peut demander des données ou des services à un autre logiciel, sans avoir accès à son code source ni à ses mécanismes internes. La métaphore du serveur de restaurant est souvent utilisée : le client (votre application) passe une commande au serveur (l’API), qui transmet la demande en cuisine (le serveur distant) et rapporte le résultat.
Cette abstraction a des conséquences majeures sur l’architecture des systèmes informatiques. Deux équipes peuvent travailler sur des technologies totalement différentes — un frontend en JavaScript et un backend en Python — et communiquer parfaitement via une API bien définie. La séparation des responsabilités devient nette, les mises à jour sont plus simples, et l’interopérabilité entre services tiers devient possible sans friction.
Les APIs ne sont pas un concept nouveau. Elles existent depuis les débuts de la programmation sous différentes formes. Ce qui a changé, c’est leur exposition sur le web. Avec l’essor d’internet, les APIs web sont devenues le standard pour connecter des systèmes distribués à l’échelle mondiale. Des acteurs comme le W3C ou l’OpenAPI Initiative ont contribué à formaliser des standards permettant une meilleure interopérabilité entre les plateformes.
Aujourd’hui, une API peut exposer des fonctionnalités de paiement (comme Stripe), de géolocalisation, d’authentification ou de traitement de données. Les entreprises monétisent leurs APIs comme des produits à part entière. Le modèle économique dit « API-first » repose entièrement sur cette logique : construire d’abord une interface programmatique solide, puis bâtir les interfaces utilisateur par-dessus. Cette approche réduit la duplication de code et facilite l’extension des fonctionnalités à de nouveaux canaux (mobile, IoT, partenaires tiers).
REST : le style architectural qui a redéfini le web
REST (Representational State Transfer) est un style d’architecture pour concevoir des services web, formalisé par Roy Fielding dans sa thèse de doctorat en 2000. Ce n’est pas un protocole strict, mais un ensemble de contraintes architecturales. Une API est dite « RESTful » lorsqu’elle respecte ces contraintes, notamment l’utilisation des méthodes HTTP standard (GET, POST, PUT, DELETE) et une organisation autour de ressources identifiées par des URLs.
Le principe central de REST est la représentation des ressources. Chaque entité du système (un utilisateur, une commande, un article) correspond à une URL unique. Pour récupérer un utilisateur, on envoie une requête GET sur /users/42. Pour le modifier, un PUT sur la même URL. Cette logique rend les APIs REST intuitives à comprendre et à utiliser, même pour des développeurs qui découvrent l’interface.
REST repose sur un modèle sans état (stateless) : chaque requête doit contenir toutes les informations nécessaires pour être traitée, sans que le serveur conserve de contexte entre deux appels. Ce choix simplifie la scalabilité horizontale des serveurs. Ajouter des instances supplémentaires pour absorber la charge devient trivial puisqu’aucune session n’est partagée entre les serveurs.
Les formats de données les plus courants en REST sont JSON et XML, avec une nette prédominance de JSON ces dernières années pour sa légèreté et sa compatibilité native avec JavaScript. La simplicité de REST explique sa domination dans les APIs publiques : Twitter, GitHub, Stripe, Spotify, toutes ces plateformes exposent des APIs REST accessibles à n’importe quel développeur avec une clé d’authentification.
REST présente néanmoins des limites. Le problème du sur-fetching (recevoir plus de données que nécessaire) et du under-fetching (devoir enchaîner plusieurs requêtes pour obtenir toutes les données voulues) est réel dans des architectures complexes. Ces limitations ont directement motivé la création de GraphQL.
SOAP, le protocole des systèmes d’entreprise
SOAP (Simple Object Access Protocol) précède REST dans l’histoire du web. Développé initialement par Microsoft à la fin des années 1990, il a été standardisé par le W3C et a longtemps dominé les architectures d’entreprise. Contrairement à REST, SOAP est un protocole complet, avec des spécifications précises sur la structure des messages, la gestion des erreurs et la sécurité.
Un message SOAP est une enveloppe XML structurée en plusieurs parties : un en-tête (header) optionnel pour les métadonnées comme l’authentification, et un corps (body) contenant la requête ou la réponse. Cette verbosité XML est souvent citée comme le principal défaut de SOAP, mais elle apporte en contrepartie une rigueur formelle que certains systèmes exigent.
SOAP fonctionne indépendamment du protocole de transport. Il peut s’utiliser sur HTTP, mais aussi sur SMTP ou d’autres protocoles. Cette flexibilité est précieuse dans des environnements d’entreprise où les systèmes legacy communiquent via des canaux variés. Les services financiers, les systèmes de santé ou les administrations publiques utilisent encore massivement SOAP pour des raisons de conformité réglementaire et d’interopérabilité avec des systèmes anciens.
Le contrat entre le client et le serveur est formalisé par un fichier WSDL (Web Services Description Language), qui décrit précisément les opérations disponibles, les types de données attendus et les formats de réponse. Cette description formelle permet la génération automatique de code client dans de nombreux langages, ce qui réduit les erreurs d’intégration dans des contextes où la fiabilité prime sur la rapidité de développement.
Choisir SOAP en 2024 n’est pas un aveu de retard technologique. C’est souvent une nécessité imposée par l’écosystème existant ou par des exigences de sécurité transactionnelle (WS-Security) que REST ne couvre pas nativement avec le même niveau de standardisation.
GraphQL : interroger une API comme une base de données
GraphQL a été introduit par Facebook en 2012 pour résoudre des problèmes concrets rencontrés lors du développement de l’application mobile. Le constat était simple : les APIs REST existantes renvoyaient trop ou pas assez de données, et multiplier les endpoints pour chaque cas d’usage devenait ingérable. GraphQL propose une approche radicalement différente : un seul endpoint, et c’est le client qui décrit précisément les données dont il a besoin.
Une requête GraphQL ressemble à une description de la structure de données attendue. Si vous voulez le nom et l’email d’un utilisateur ainsi que les titres de ses trois derniers articles, vous le demandez exactement ainsi dans la requête. Le serveur renvoie précisément cela, ni plus ni moins. Ce modèle élimine le sur-fetching et réduit drastiquement le nombre de requêtes réseau nécessaires pour composer une vue complexe.
GraphQL repose sur un schéma fortement typé, défini côté serveur, qui décrit l’ensemble des données disponibles et leurs relations. Ce schéma sert de contrat entre frontend et backend, et permet une introspection native : n’importe quel client peut interroger le schéma pour découvrir les capacités de l’API. Des outils comme GraphiQL ou Apollo Studio exploitent cette propriété pour offrir une expérience de développement très productive.
L’adoption de GraphQL a été rapide dans les startups et les équipes produit travaillant sur des applications à fort trafic ou des architectures microservices. GitHub a migré son API publique vers GraphQL en 2016. Shopify, Twitter et de nombreuses autres plateformes l’ont suivi. Le site officiel graphql.org maintient une documentation de référence et recense les implémentations disponibles dans une vingtaine de langages.
GraphQL n’est pas sans défauts. La gestion du cache HTTP est plus complexe qu’avec REST (toutes les requêtes passent par POST sur un seul endpoint). La protection contre les requêtes abusives demande une attention particulière (depth limiting, query complexity). Et la courbe d’apprentissage reste plus élevée que REST pour les équipes qui débutent.
Tableau comparatif : REST, SOAP et GraphQL
| Caractéristiques | REST | SOAP | GraphQL |
|---|---|---|---|
| Format des données | JSON, XML | XML uniquement | JSON |
| Protocole | HTTP | HTTP, SMTP, etc. | HTTP |
| Contrat formel | OpenAPI (optionnel) | WSDL (obligatoire) | Schéma GraphQL |
| Avantages | Simplicité, adoption large, cache HTTP natif | Sécurité avancée, interopérabilité enterprise | Flexibilité des requêtes, pas de sur-fetching |
| Inconvénients | Sur-fetching possible, endpoints multiples | Verbosité XML, complexité de mise en œuvre | Cache complexe, courbe d’apprentissage |
| Cas d’usage typique | APIs publiques, applications web classiques | Systèmes bancaires, santé, legacy | Applications mobiles, microservices, produits complexes |
Quelle technologie choisir pour votre projet ?
La réponse dépend du contexte, pas d’une hiérarchie de valeur entre les trois approches. REST reste le choix par défaut pour la grande majorité des projets web : sa simplicité, la richesse des outils disponibles et la familiarité des développeurs en font une option difficile à battre pour des APIs publiques ou des projets avec des équipes de taille modeste.
SOAP s’impose dès que l’environnement l’exige. Intégrer un système bancaire, un logiciel de gestion hospitalière ou une administration publique implique souvent de travailler avec des services SOAP existants. Résister à cette réalité ne sert à rien. Maîtriser SOAP reste une compétence utile pour tout développeur travaillant dans des contextes enterprise.
GraphQL apporte une vraie valeur dans des architectures où la flexibilité des requêtes est déterminante : applications mobiles avec des contraintes de bande passante, frontends qui agrègent des données de sources multiples, ou équipes produit qui itèrent rapidement sur leurs interfaces. L’OpenAPI Initiative et la communauté GraphQL publient régulièrement des mises à jour sur les bonnes pratiques — les spécifications évoluent, et une veille régulière reste nécessaire pour rester à jour.
Ces trois technologies coexistent souvent dans une même organisation. Un système mature peut exposer une API REST pour ses partenaires externes, utiliser SOAP pour communiquer avec un ERP legacy, et proposer GraphQL à ses équipes frontend internes. La maîtrise de ces trois approches n’est pas un luxe pour un développeur web : c’est une réalité du terrain.