Les API sont les nouvelles interfaces en ligne de commande. Mais lorsqu’il s’agit de déterminer le type d’API que vous développez, l’approche déclarative règne en maître.
Une API — une interface de programmation d’application — est aujourd’hui une fonctionnalité essentielle. Les organisations en disposent au niveau métier afin de favoriser l’intégration des partenaires et l’innovation par ce que l’on appelle les « développeurs citoyens ». Les applications en disposent pour faciliter l’intégration et dissocier la logique métier — susceptible de changer fréquemment — des interfaces, qui devraient évoluer moins souvent. Les infrastructures en disposent également. Des commutateurs aux routeurs, des services applicatifs aux intergiciels et aux bases de données, les composants d’infrastructure qui constituent les pipelines de livraison et de déploiement sont dotés d’API.
Cela devrait, en soi, nous inciter à prendre du recul et à réfléchir à ce que cela implique pour la communauté NetOps émergente. En effet, si les organisations ont tendance à standardiser quelques composants clés de leur infrastructure applicative, elles sont moins susceptibles de se limiter à quelques composants clés pour leur infrastructure réseau et leurs services applicatifs.
Parmi les seize services applicatifs différents utilisés en moyenne par les entreprises pour rendre leurs applications plus rapides et plus sûres, il est certain que leur mise à disposition repose sur plus d’une poignée de composants d’infrastructure. Même en supposant généreusement un ratio de trois services applicatifs par composant, cela représente tout de même cinq équipements différents, avec cinq API différentes.
Le problème, c’est que les fournisseurs d’infrastructure ont souvent pris l’affirmation « L’API est la nouvelle CLI » un peu trop au pied de la lettre. Autrement dit, l’API n’est qu’un reflet de la CLI accessible via REST.
Quiconque a déjà utilisé des interfaces en ligne de commande sur différents composants d’infrastructure sait que la navigation dans ces interfaces reflète très fidèlement le modèle objet de l’infrastructure. Souvent, les API ne font que transposer cette conception telle quelle vers HTTP. Par conséquent, ceux qui souhaitent tirer parti de l’API doivent nécessairement apprendre également le modèle objet de l’équipement concerné.
Ce niveau d’abstraction freine les progrès de l’automatisation et de l’orchestration, car nous devons désormais trouver non seulement des spécialistes de l’automatisation, mais aussi des spécialistes possédant une certaine expertise dans au moins cinq modèles d’infrastructure réseau différents. Le niveau d’expertise requis exige souvent également des connaissances métier, allant d’une compréhension élémentaire de la configuration des VLAN et du routage jusqu’aux relations entre les serveurs virtuels, les adresses IP virtuelles, les nœuds, les membres et les pools.
Exposer la complexité sous-jacente de l’infrastructure nuit à son adoption et à la mise en œuvre de l’automatisation. Les interfaces doivent faire abstraction des modèles et de la logique afin de préserver les utilisateurs et les opérateurs de cette complexité. C’est ce que fait l’interface graphique, en évitant d’avoir à parcourir des hiérarchies d’objets pour configurer un service simple.
C’est pourquoi il est souvent frustrant de constater que l’API a réintroduit ce cauchemar de navigation.
Ce problème n’est pas propre aux infrastructures réseau et applicatives. Ainsi, dans son étude « La valeur croissante des API », MuleSoft a constaté que la principale demande des clients et partenaires en matière d’intégration d’API — citée par 47 % des répondants — concernait des « API personnalisées répondant à un besoin métier spécifique ». Venaient ensuite une meilleure documentation (19 %), des modèles d’intégration « sans code » (19 %) et des wrappers SDK pour les API dont ils ont besoin et qu’ils utilisent (13 %).
Tout cela peut se résumer à un appel à la simplification. Et dans le domaine technologique, simplifier signifie faire abstraction de la complexité.
Et cela nous amène au cœur de cet article : les interfaces déclaratives constituent précisément cette abstraction. En simplifiant les interfaces aujourd’hui utilisées pour provisionner, configurer, gérer et intégrer l’infrastructure, elles démocratisent l’accès à l’infrastructure et ouvrent de nouvelles perspectives.
Déclaratif ou impératif
D’une manière générale, les approches déclarative et impérative peuvent toutes deux être considérées comme des types d’API. Les API impératives sont celles auxquelles on pense généralement lorsque quelqu’un parle d’API. Elles indiquent précisément au système cible comment effectuer une opération. Si vous souhaitez ajouter un serveur virtuel, vous devez lui indiquer exactement comment procéder, même si cela nécessite cinq, dix appels d’API distincts, voire davantage.
Cela signifie qu’il faut lui demander de créer un objet spécifique doté des attributs appropriés, par exemple un nœud avec une adresse IP. Il faut ensuite demander séparément au système de créer, en lui donnant un nom, le pool auquel ce nœud sera affecté. Puis il faut… enfin, vous avez compris. Les API impératives imposent à leurs utilisateurs de comprendre non seulement le système et son modèle objet, mais aussi les étapes nécessaires pour obtenir les résultats souhaités.
C’est le prix à payer en matière d’API avec l’approche impérative.
Cela dit, les API impératives ne sont pas mauvaises en soi. Elles sont très importantes lorsque vous développez une interface graphique ou intégrez d’autres systèmes qui nécessitent le niveau de granularité offert par une API impérative. Nous avons également besoin d’API impératives, mais pas pour l’automatisation et l’intégration destinées aux équipes NetOps et DevOps.
Mais pour les autres, il n’est pas nécessaire de connaître un tel niveau de détail. En réalité, exiger des connaissances aussi approfondies peut être décourageant et ralentir les efforts d’automatisation et d’orchestration. Cela ne favorise certainement pas la démocratisation de l’infrastructure ni la mise en place de modèles en libre-service pour les équipes DevOps et les développeurs, et encore moins pour les équipes NetOps qui ne sont pas spécialisées dans le domaine d’infrastructure concerné.
C’est là que les API déclaratives entrent en jeu.
Les interfaces déclaratives précisent ce que vous souhaitez faire et laissent au système le soin de déterminer la logique et le flux de travail. Ainsi, plutôt que d’indiquer précisément au système de créer un nœud et un pool et d’exécuter toute la logique appropriée sur les objets requis, vous les décrivez ainsi que leurs relations.
Certaines interfaces déclaratives utilisent JSON, d’autres XML, et certaines ont même encore recours à de simples données de formulaire. Elles ont toutes en commun de partir du principe que les données décrivent les objets de manière simple et directe, sans nécessiter une compréhension approfondie des modèles d’objets et des hiérarchies du système.
Par exemple, cette déclaration est assez lisible pour un être humain. Elle suppose une compréhension élémentaire du modèle objet, mais pas au point d’exiger une certification sur un produit spécifique pour pouvoir la rédiger :
"web_pool": { "class": "Pool", "monitors": [ "http" ], "members": [ { "servicePort": 80, "serverAddresses": [ "192.0.1.10", "192.0.1.11" ] } ] }
C’est ici que la valeur des interfaces déclaratives devient évidente : elles réduisent les connaissances métier requises ainsi que la complexité du provisionnement et de la configuration de l’infrastructure. Grâce à cette réduction du niveau d’expertise nécessaire, les équipes NetOps peuvent non seulement travailler plus rapidement et plus efficacement, mais aussi encourager les équipes DevOps et les développeurs à tirer parti de cette fonctionnalité.
L’adoption des interfaces déclaratives comme méthode standard de gestion de l’infrastructure élargit immédiatement le vivier de talents sur lequel vous pouvez vous appuyer pour proposer des fonctionnalités en libre-service et d’automatisation avancée. L’interface déclarative ci-dessus ne nécessite que très peu d’explications pour que les équipes DevOps et les développeurs puissent la comprendre et l’utiliser. En revanche, une interface impérative exigerait de consacrer beaucoup plus de temps à l’apprentissage du modèle et des workflows propres à l’infrastructure avant de pouvoir espérer obtenir des résultats.
Les interfaces déclaratives démocratisent l’infrastructure en simplifiant le provisionnement, la configuration et la gestion nécessaires à l’automatisation des pipelines de déploiement et à l’intégration des systèmes avec d’autres services d’infrastructure. Cette démocratisation permet une automatisation plus rapide et plus intelligente, tout en favorisant la collaboration et la coopération entre les différents domaines opérationnels, indispensables pour tirer parti des approches NetOps et DevOps.
À propos de l’auteur

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés

Pourquoi devriez-vous vous intéresser à WebAssembly ?
WebAssembly (Wasm) est un jeu d’instructions binaires portable, rapide et sécurisé, qui permet d’exécuter des applications hautes performances sur n’importe quelle plateforme.
Trois choses à savoir sur les applications d’IA
Les applications d’IA sont des applications modernes, mais elles présentent certaines particularités. Découvrez les points essentiels à connaître sur les applications basées sur l’IA.
État des lieux de la stratégie applicative 2022 : il est temps de moderniser les opérations
Il est devenu évident que, pour maintenir la dynamique de leur transformation numérique, les organisations doivent recentrer leurs efforts sur les fonctions métier. Si les expériences destinées aux clients restent prioritaires, il est également indispensable de permettre la numérisation de fonctions telles que les services juridiques, les ressources humaines et la finance. Les DSI prennent donc les commandes, tandis que la transformation numérique passe de la modernisation des applications à celle des opérations.
Clouds multiples ou multicloud : faciliter la transition
La gestion et la sécurisation des charges de travail deviennent complexes à mesure que les entreprises adoptent une stratégie de cloud connecté. Découvrez comment F5 répond au besoin d’une nouvelle approche de la mise en réseau multicloud.
L’expérience client dépend de la visibilité
Une enquête menée par Dimensional Research auprès de plus de 3 000 utilisateurs d’applications mobiles a confirmé ce que beaucoup d’entre nous pensent des attentes actuelles des clients.
Transformation numérique et explosion du portefeuille d’applications
La transformation numérique stimule la croissance des portefeuilles d’applications et modifie la manière dont celles-ci sont développées, déployées, intégrées et, en définitive, utilisées.