Intégration / API et évolution des architectures
Pourquoi on passe progressivement des accès directs aux bases à des services web - et ce que cela change dans les architectures.
L'API
Un contrat d'échange - REST, verbes HTTP, JSON.
Pourquoi s'éloigner
Couplage, fragilité, sécurité, évolutivité.
Ce que ça change
Stocker, exposer, orchestrer - des rôles distincts.
Consommer
Appeler, recevoir, extraire, utiliser.
Le terrain
Du réflexe SQL au réflexe service.
Définition
Qu'est-ce qu'une API
Un contrat d'échange entre deux systèmes, indépendant de la manière dont chacun est construit à l'intérieur
Une API (Application Programming Interface) définit ce qu'un système accepte de fournir à un autre - et sous quelle forme - sans que le consommateur ait besoin de connaître l'implémentation interne : structure des tables, moteur de base de données, logique de calcul.
Dans le monde des services web, REST (Representational State Transfer) est aujourd'hui le standard le plus répandu.
Les principes REST
- →Chaque ressource est identifiée par une URL -
/api/etudiants/12345 - →Les verbes HTTP décrivent l'action : GET pour lire, POST pour créer, PUT pour mettre à jour, DELETE pour supprimer
- →Les échanges se font généralement en JSON, un format léger et lisible
- →Les codes de retour HTTP indiquent le résultat : 200 (succès), 401/403 (droits), 404 (absent), 500 (erreur serveur)
Ce qu'il faut retenir
Une API n'est pas qu'une question technique - c'est un engagement. Tant que le contrat (les données exposées, leur format) ne change pas, le fournisseur peut faire évoluer tout ce qu'il veut derrière, sans que le consommateur s'en aperçoive.
Enjeux
Pourquoi on s'éloigne de l'accès direct aux bases
Une facilité qui a un coût, surtout visible dans la durée
Techniquement, rien n'empêche une application de se connecter directement à la base d'une autre pour aller y chercher une donnée. C'est même souvent le chemin le plus rapide dans l'instant. Mais cette facilité se paie, généralement plus tard et ailleurs.
Ce que l'accès direct fragilise
- !Couplage fort - un accès direct crée une dépendance à la structure interne (noms de tables, de colonnes, types). Le consommateur devient captif d'une implémentation qu'il ne maîtrise pas.
- !Fragilité invisible - un changement de schéma, un renommage de colonne, une migration de moteur peuvent casser silencieusement des flux dont personne ne se souvient qu'ils existent.
- !Sécurité et gouvernance diluées - un accès direct expose potentiellement bien plus que ce dont le consommateur a réellement besoin, et rend difficile de savoir qui accède à quoi.
- !Évolutivité bridée - tant que des consommateurs externes dépendent directement du schéma d'une base, celle-ci ne peut plus évoluer librement.
Ce que ça signifie pour une DSI universitaire
Un référentiel exposé par API peut changer de base de données, de moteur, d'hébergement - tant que le contrat REST reste stable, les applications qui le consomment n'ont rien à changer. C'est l'inverse d'un accès direct, où le moindre changement interne se répercute immédiatement sur tout le monde.
Architecture
Ce que ça change dans l'architecture
Pas une opposition ancien/nouveau - une clarification des rôles, à des niveaux différents
La base de données sert à stocker et gérer les données. Le service (API) sert à les exposer proprement aux consommateurs, sans exposer la structure interne. Les outils d'intégration peuvent ensuite consommer, transformer et recombiner ces services pour construire des flux plus complexes.
Le changement de réflexe
Une habitude construite sur l'accès direct pense d'abord « j'ai une base → je fais une requête ». Une architecture orientée services pense plutôt « j'ai besoin d'une donnée → je consomme un service qui me la fournit ».
Référentiels internes
↓
Service REST
↓
données utiles
↓
application consommatrice
Le service comme contrat entre applications
- →Le consommateur n'a plus besoin de connaître les sources internes ni leur structure - il demande simplement ce dont il a besoin.
- →Le service répond selon un contrat stable, quelle que soit l'évolution des sources derrière.
Pratique
Consommer une API, en pratique
Un principe qui reste le même quel que soit l'outil utilisé pour le mettre en œuvre
1
Appeler
Le service (une URL, une méthode HTTP, éventuellement une authentification).
2
Recevoir
Une réponse structurée, le plus souvent en JSON.
3
Extraire
Les champs utiles, pour les rendre exploitables dans son propre traitement.
4
Utiliser
Ces données dans l'application ou le flux qui en a besoin.
Un mécanisme indépendant de l'outil
Ce mécanisme est le même qu'on l'appelle depuis un script, une application, ou un outil d'intégration graphique - seule la manière de l'orchestrer change. C'est une manipulation qui se comprend mieux en la pratiquant sur un cas concret qu'en lisant uniquement la documentation.
Regard
Le regard du terrain
Le réflexe technique ne change pas du jour au lendemain
Avec des habitudes construites sur l'accès direct aux bases, le premier instinct reste naturellement « j'ai une base → je fais un SELECT ». Passer à « j'ai besoin d'une donnée → je consomme un service » demande un temps d'adaptation, même quand on comprend intellectuellement l'intérêt de l'approche.
Une observation utile en arrivant sur un nouveau SI
Il arrive qu'on commence à explorer des données directement dans les bases pour comprendre un problème, au moment même où, ailleurs dans le SI, une couche de service est déjà en cours de construction pour exposer proprement ces mêmes données. Ce n'est pas une perte de temps - comprendre les données à la source aide à mieux qualifier ce qu'on attend ensuite d'un service. Mais ça vaut le coup de se renseigner tôt sur ce qui existe déjà ou se construit, avant de s'installer durablement dans un accès direct.
Le regard sur l'intégration par API
Une API REST est un contrat, pas un simple mécanisme technique : tant qu'il reste stable, ce qu'il y a derrière peut évoluer librement.
L'accès direct aux bases est pratique dans l'instant, mais crée un couplage fragile qui se paie dans la durée.
Le bon réflexe à construire : penser d'abord service, avant de penser accès direct - surtout quand le système est amené à durer.
L'API - un contrat
Pourquoi - couplage et fragilité
Architecture - rôles distincts
Consommer - appeler et extraire
Le terrain - changer de réflexe