Dans la proposition initiale pour Internet, Tim Berners-Lee écrivait :
Un outil générique pourrait peut-être être créé pour permettre à toute base de données utilisant un SGBD métier d’être affichée comme une vue hypertexte.
Nous avons obtenu ces vues hypertexte, dans le genre d’API, mais pas de manière générique. Les applications Web basées sur une base de données ont développé des API qui ont généré diverses sorties XML et ensuite JSON. Les langages de programmation ont développé des bibliothèques pour aider les concepteurs à utiliser ces sorties. Découvrir comment utiliser chaque API individuelle était un défi, et joindre les sorties de plusieurs API beaucoup plus.
En 2009, je développais un système pour combiner les détails du calendrier à partir de nombreuses sources. Il leur a posé la même préoccupation à tous : quels événements sont organisés pour un lieu et une heure proposés ? Pour ce faire, il a dû utiliser une demi-douzaine d’API, chacune nécessitant une méthode différente pour faire une demande et déballer la réaction.
Quand j’ai découvert Job Astoria, j’étais un fan immédiat. Astoria était la vue hypertexte générique des bases de données dont nous avions besoin. Avec Astoria superposé, chaque base de données pourrait automatiquement proposer une API par défaut. Si la demi-douzaine de systèmes que j’interrogeais pour des occasions supportaient quelque chose comme Astoria, aucun n’aurait eu besoin de développer des API sur mesure et tous seraient interrogeables dans la même méthode constante.
Le concept s’est développé en Open Data, alias OData, une norme OASIS depuis 2014. En théorie, toute application Web basée sur une base de données pourrait désormais arborer une « tête OData » qui fournirait une API par défaut, ne nécessitant aucun code à composer par les développeurs de l’application, et aucune toute nouvelle demande /procédures de réponse à apprendre par les concepteurs utilisant l’API.
En pratique, cela ne s’est généralement pas produit.
Plus que jamais, la construction d’applications logicielles nécessite que les développeurs créent des services utilisant une expansion croissante des API. Il existe souvent une bibliothèque pour couvrir chaque API dans le langage d’option de votre programme, ce qui vous épargne l’effort d’effectuer des appels REST bruts et d’analyser les résultats. Chaque wrapper a sa propre façon de représenter les résultats, donc lors de la création d’un service multi-API, vous devez stabiliser ces représentations. Étant donné que l’intégration des résultats s’effectue d’une manière spécifique à la langue, votre service est connecté à cette langue. Et si ce langage est JavaScript ou Python ou Java ou C#, ce n’est peut-être pas la méthode la plus universelle et la plus puissante pour interroger (ou mettre à jour) une base de données.
Quelle est la véritable meilleur moyen? Il a toujours été dissimulé à la vue de tous : SQL. Aguerri pendant des années et ayant dépassé le modèle relationnel pur, SQL s’est en fait rétabli comme l’interface utilisateur par excellence pour l’information. Et il est placé pour devenir l’unificateur d’API dont nous avons besoin plus que jamais.
Enveloppeurs de données étrangers pour les API
Steampipe (steampipe.io) est un outil open source qui apporte des données de API variées et l’utilise pour occuper des tables dans une base de données. La base de données est Postgres, qui est, de nos jours, une plate-forme sur laquelle développer toutes sortes de systèmes de type base de données en créant des extensions qui personnalisent profondément le noyau. Une classe d’extension Postgres, le wrapper d’informations étrangères (FDW), crée des tables à partir de données externes. Steampipe intègre une instance de Postgres qui charge un wrapper d’informations étrangères orienté API. Le FDW interagit à son tour avec une famille croissante de plug-ins qui consomment des API et alimentent les informations via le FDW dans les tables Postgres.
Pour rendre ces abstractions concrètes, demandez-vous comment vous résoudriez le problème suivant. Vous exploitez des services AWS publics et vous souhaitez savoir si l’un de leurs points de terminaison apparaît comme vulnérable dans Shodan, un service qui analyse les points de terminaison publics. Votre service ressemble probablement à ceci :
- Découvrez comment utiliser l’API AWS qui découvre vos points de terminaison
- Apprenez à utiliser l’API Shodan pour vérifier vos points de terminaison
- Apprenez à intégrer ces 2 API pour résoudre le problème
Voici le service Steampipe.
« ‘choose
a.instance _ id,
s.ports,
s.vulns,
a.security _groups
depuis
aws_ec2_instance a
jointure gauche
shodan_host s sur a. public _ ip_address = s.ip
où
a.public _ ip_address n’est pas nul ;
« » »
————– ——- ———- ——————– ————- ————————————————
|id_instance|ports|vulns|groupes_sécurité|
——————— ———- —- —————- ———————————- —————————
|i-0dc60dd191cb84239|
|i-042a51a815773780d|[80,22]|
|i-00cf426db9b8a58b6|[22]|
|i-0e97f373db42dfa3f|[22,111]|[« CVE-2018-15919 « ]|[]|
——————— ———- ——————- – ————————————————- ————
« ‘Les deux tables enregistrées ici sont fournies par les plug-ins Steampipe pour AWS et Shodan. Le tout premier mappe le catalogue tentaculaire des API AWS sur (actuellement) 269 tables ; le second fournit une douzaine de tables Shodan.
Vous configurez ces plug-ins pour vérifier les API avec exactement les mêmes qualifications dont vous auriez besoin si vous utilisiez directement les API. Vous n’avez pas besoin de connaître quoi que ce soit d’autre sur les appels REST sous-jacents ou les bibliothèques couvertes autour d’eux. Le service est composé de tables qui fonctionnent de la même manière dans et entre les API. Vous les examinez (aws_ec2_instance, shodan_host) pour trouver les noms de leurs colonnes, et vous les rejoignez dans la méthode SQL séculaire.
Un plug-in pour chaque API unique
Il est clair que cette solution à deux API dépend de l’existence de plug-ins pour mapper les deux API aux tables. Si les deux services exécutaient OData, cela ne serait pas nécessaire. Les API seraient automatiquement interrogeables, mais peut-être pas joignables avec la sophistication offerte par SQL. Ces deux services, comme la majorité d’entre eux, ne fournissent pas d’interface combinée à leurs API. Donc, ce mariage doit être superposé à eux. Le SDK de plug-in de Steampipe facilite la méthode pour les auteurs de plug-in en faisant abstraction de la gestion des connexions, du raisonnement des nouvelles tentatives, de la mise en cache et, bien sûr, du mappage des résultats de l’API aux tables.
Les plug-ins Steampipe sont composés en Go. Ils tirent parti de la vaste brochure des bibliothèques Go qui enveloppent les API. Seuls les auteurs de plug-ins doivent comprendre cela. En tant que développeur traitant de Steampipe, vous ne voyez que des tables et vous ne composez que du SQL. De nos jours, parce que SQL s’est développé, cela inclut des fonctionnalités telles que les expressions de table communes (alias CTE ou stipulations WITH) et les colonnes JSON. Cependant, il s’agit toujours simplement de SQL.
Est-il possible de développer de tels plug-ins pour chaque API ? Eh bien, Steampipe a été introduit début 2021 avec une poignée de plug-ins, aujourd’hui il y en a plus de 60, et le nombre augmente rapidement. La plupart d’entre eux ont en fait été composés par le groupe central, mais les contributions externes se multiplient. Grâce au plug-in SDK, qui fait le gros du travail, il est simple de construire un plug-in qui mappe une API à un ensemble de tables.
Reposant sur les épaules de Postgres
En intégrant Postgres, Steampipe hérite de toutes ses capacités. Par exemple, vous pouvez joindre des tables étrangères provenant de l’API avec des tables Postgres natives. Et tandis que le principal avantage de Steampipe est l’interrogation en direct des API, vous pouvez créer des vues matérialisées pour continuer ces données et composer des fonctions Postgres à exécuter dessus. Vous pouvez même charger d’autres extensions Postgres et les utiliser avec les tables Steampipe. L’extension tablefunc intégrée de Postgres, par exemple, peut faire des tableaux croisés, en SQL, avec des informations de feuille de calcul à partir du plug-in Google Sheets de Steampipe.
Un autre avantage de l’intégration de Postgres : tout client d’API compatible avec Postgres peut se connecter à Tuyau de vapeur. Cela se compose d’outils de ligne de commande tels que psql et d’outils basés sur une interface graphique tels que Tableau, Power BI, Metabase et Superset qui apportent visualisation et interactivité aux informations d’API en direct.
Postgres ne sera peut-être jamais aussi couramment intégré que le SQLite commun, mais il est plus performant et, de manière significative, il est utilisé pour alimenter un environnement d’outils interopérables pour traiter les informations. Steampipe étend Postgres pour fournir un accès unifié aux API et un environnement SQL typique dans lequel prendre en compte les données fournies.
Jon Udell est le responsable de la communauté Steampipe chez Turbot.
— Nouveau
Le forum Tech Online offre un lieu pour vérifier et discuter de l’innovation d’entreprise émergente avec une profondeur et une ampleur sans précédent. La sélection est subjective, basée sur notre sélection des technologies que nous pensons importantes et les plus intéressantes pour les lecteurs d’InfoWorld. InfoWorld refuse les supports marketing pour publication et se réserve le droit de modifier tout le matériel fourni. Envoyez toutes les questions à newtechforum@infoworld.com.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
