Com SQL pot unificar l’accés a les API

A la proposta original per a la World Wide Web, Tim Berners-Lee va escriure:

Potser es podria fer una eina genèrica per permetre que qualsevol base de dades que utilitzi un SGBD comercial es mostri com a vista d’hipertext.

Vam obtenir aquestes vistes d’hipertext, en forma d’API, però no de manera genèrica. Les aplicacions web recolzades per bases de dades van fer créixer API que van generar diferents sortides XML i després JSON. Els llenguatges de programació van fer créixer biblioteques per ajudar els desenvolupadors a consumir aquestes sortides. Aprendre a utilitzar cada API individual va ser un repte, unint les sortides de diverses API encara més.

L’any 2009 estava construint un sistema per combinar informació del calendari de moltes fonts. A tots ells es va fer la mateixa pregunta: Quins esdeveniments estan programats per a un lloc i hora determinats? Per fer-ho, va haver d’utilitzar mitja dotzena d’API, cadascuna requeria una manera diferent de fer una sol·licitud i desempaquetar la resposta.

Així que quan vaig conèixer el Projecte Astoria vaig ser un fan immediat. Astoria era la visió genèrica d’hipertext de les bases de dades que necessitàvem. Amb Astoria a la part superior, cada base de dades podria proporcionar automàticament una API predeterminada. Si la mitja dotzena de sistemes que estava consultant per a esdeveniments admetien alguna cosa com Astoria, cap hauria necessitat inventar API a mida i tots es podrien consultar de la mateixa manera coherent.

La idea va madurar com a Open Data, també conegut com OData, un estàndard d’OASIS des del 2014. En principi, qualsevol aplicació web recolzada per bases de dades ara podria portar un “cap OData” que proporcionés una API predeterminada, sense que els desenvolupadors de l’aplicació hagin escrit cap codi. , i no hi ha protocols de sol·licitud/resposta nous que els desenvolupadors que utilitzin l’API.

A la pràctica això no ha passat gairebé mai.

Més que mai, la construcció de programari requereix que els desenvolupadors componguin solucions mitjançant una proliferació creixent d’API. Sovint hi ha una biblioteca per embolicar cada API en el llenguatge de programació que trieu, de manera que us estalvieu l’esforç de fer trucades REST en brut i analitzar els resultats. Però cada embolcall té la seva pròpia manera de representar els resultats, de manera que quan es compon una solució multi-API heu de normalitzar aquestes representacions. Com que la combinació de resultats es fa d’una manera específica de l’idioma, la vostra solució està lligada a aquest idioma. I si aquest llenguatge és JavaScript o Python o Java o C#, probablement no és la manera més universal i potent de consultar (o actualitzar) una base de dades.

Quina és la millor manera? Ha estat amagat a la vista durant tot el temps: SQL. Endurit durant dècades i evolucionat més enllà del model relacional pur, SQL s’ha restablert com la interfície preeminent per a les dades. I està posicionat per convertir-se en l’unificador d’API que necessitem més que mai.

Embolcalls de dades estrangeres per a API

Steampipe (steampipe.io) és una eina de codi obert que obté dades de diverses API i les utilitza per omplir taules en una base de dades. La base de dades és Postgres, que avui dia és una plataforma sobre la qual construir tot tipus de sistemes semblants a bases de dades mitjançant la creació d’extensions que personalitzen profundament el nucli. Una classe d’extensió Postgres, l’embolcall de dades estrangeres (FDW), crea taules a partir de dades externes. Steammpipe incorpora una instància de Postgres que carrega un embolcall de dades estrangers orientat a API. El FDW al seu torn es comunica amb una família creixent de complements que consumeixen API i alimenten les dades a través del FDW a les taules Postgres.

Per concretar aquestes abstraccions, pregunteu-vos com resoldreu el problema següent. Opereu serveis públics d’AWS i us agradaria saber si algun dels seus punts finals apareix com a vulnerable a Shodan, un servei que analitza els punts finals públics. La vostra solució probablement s’assembla a això:

  1. Obteniu informació sobre com utilitzar l’API d’AWS que troba els vostres punts finals
  2. Apreneu a utilitzar l’API Shodan per comprovar els vostres punts finals
  3. Obteniu informació sobre com combinar aquestes dues API per respondre la pregunta

Aquí teniu la solució de Steammpipe.

```
select
  a.instance_id,
  s.ports,
  s.vulns,
  a.security_groups
from
  aws_ec2_instance a
left join
  shodan_host s on a.public_ip_address = s.ip
where
  a.public_ip_address is not null;
```
```
+---------------------+----------+--------------------+-------------------------------------------------------------+
| instance_id         | ports    | vulns              | security_groups                                             |
+---------------------+----------+--------------------+-------------------------------------------------------------+
| i-0dc60dd191cb84239 |    |              | [{"GroupId":"sg-042fe79169eb42818","GroupName":"lockdown"}] |
| i-042a51a815773780d | [80,22]  |              | [{"GroupId":"sg-042042bac705630f4","GroupName":"bastion"}]  |
| i-00cf426db9b8a58b6 | [22]     |              | [{"GroupId":"sg-0423f79169eb42818","GroupName":"default"}]  |
| i-0e97f373db42dfa3f | [22,111] | ["CVE-2018-15919"] | [{"GroupId":"sg-0423f79169eb42818","GroupName":"default"}]  |
+---------------------+----------+--------------------+-------------------------------------------------------------+
```

Les dues taules que s’uneixen aquí les proporcionen els connectors de Steammpipe per a AWS i Shodan. El primer mapa el catàleg extens d’API d’AWS a (actualment) 269 taules; el segon ofereix una dotzena de taules Shodan.

Configureu aquests connectors per autenticar-se a les API amb les mateixes credencials que necessitaríeu si feu servir les API directament. Però no cal que sapigueu res més sobre les trucades REST subjacents o les biblioteques que les envolten. La solució es fa a partir de taules que funcionen de la mateixa manera dins i entre les API. Els inspeccioneu (aws_ec2_instance, shodan_host) per descobrir els noms de les seves columnes i els uniu de la manera tradicional SQL.

Un connector per a cada API

És evident que aquesta solució de dues API depèn de l’existència de connectors per assignar ambdues API a taules. Si ambdós serveis implementessin OData, això no seria necessari. Les API es podrien consultar automàticament, tot i que probablement no es poden unir amb l’elegància que ofereix SQL. Però aquests dos serveis, com la majoria, no presenten una interfície unificada a les seves API. Així que aquesta unificació s’ha de posar a sobre d’ells. L’SDK del connector de Steammpipe suavitza el camí per als autors del connector abstraint la gestió de connexions, la lògica de reintentar, la memòria cau i, per descomptat, el mapeig dels resultats de l’API a les taules.

Els connectors de Steammpipe estan escrits a Go. Aprofiten el catàleg complet de biblioteques de Go que inclouen les API. Però només ho han de saber els autors de complements. Com a desenvolupador que treballa amb Steampipe, només veus taules i només escriviu SQL. Avui en dia, com que SQL ha evolucionat, inclou funcions com les expressions de taula comuns (també coneguts com CTE o WITH clàusules) i columnes JSON. Però encara és només SQL.

Es poden crear aquests connectors per a cada API? Bé, Steammpipe es va llançar a principis del 2021 amb un grapat de complements, avui en dia n’hi ha més de 60 i el nombre augmenta ràpidament. Fins ara, la majoria han estat escrites per l’equip principal, però les contribucions externes estan creixent. Gràcies a l’SDK del connector, que fa el treball pesat, és senzill crear un connector que assigni una API a un conjunt de taules.

Dempeus sobre les espatlles de Postgres

En incrustar Postgres, Steampipe hereta totes les seves capacitats. Així, per exemple, podeu unir-vos a taules estrangeres d’origen API amb taules natives de Postgres. I tot i que l’avantatge principal de Steampipe és la consulta en directe de les API, podeu crear vistes materialitzades per mantenir aquestes dades i escriure funcions de Postgres per operar-hi. Fins i tot podeu carregar altres extensions de Postgres i utilitzar-les amb taules Steammpipe. L’extensió tablefunc integrada de Postgres, per exemple, pot fer taules creuades, en SQL, amb dades del full de càlcul del complement de Google Sheets de Steammpipe.

Un altre avantatge d’incrustar Postgres: qualsevol client d’API compatible amb Postgres pot connectar-se a Steampipe. Això inclou eines de línia d’ordres com psql i basats en GUI com Tableau, Power BI, Metabase i Superset que aporten visualització i interactivitat a les dades de l’API en directe.

Pot ser que Postgres mai estigui tan àmpliament integrat com l’omnipresent SQLite, però és més capaç i cada cop més s’utilitza per alimentar un ecosistema d’eines interoperables per treballar amb dades. Steampipe amplia Postgres per oferir accés unificat a les API i un entorn SQL comú en el qual raonar sobre les dades que proporcionen.

Copyright © 2022 IDG Communications, Inc.

Leave a Comment

Your email address will not be published. Required fields are marked *