IL MERAVIGLIOSO MONDO DELLE API

Il meraviglioso mondo delle API

Le API, ma non quelle del miele

Amo le API.
Ma non fraintendetemi: non voglio parlarvi qui dei simpatici e utilissimi insetti che volano di fiore in fiore, anche se nella mia lunga e variegata esperienza lavorativa ho indossato qualche volta la tuta dell’apicoltore e qualche cosina riguardo al mondo delle api la potrei raccontare…

Amo le api, quindi, ma pure amo le API, quella tecnologia informatica designata dall’acronimo “Application Programming Interface”, che nella nostra lingua potrebbe suonare come “Interfaccia di programmazione delle applicazioni”.

Come dite? Preferireste che vi parli della api del miele? Sono d’accordo con voi, però le colleghe del marketing mi hanno chiesto di scrivere qualcosa sulle API e allora…

Le API, una mattone essenziale nella costruzione dei nostri sistemi

D’altra parte le colleghe del marketing hanno perfettamente ragione. In questo blog desideriamo presentare le tecnologie che stanno alla base dei sistemi progettati da Wallysoft e, se le api del miele sono fondamentali per lo sviluppo e la conservazione della vita sul nostro pianeta, le API sono un mattone essenziale nello sviluppo e nel funzionamento dei sistemi che progettiamo in Wallysoft, sia che si tratti di applicazioni per dispositivi mobili, sia che si tratti di applicazioni accessibili tramite il navigatore internet.

API che?

Questo articolo sarà un esercizio di “acronimia”, dovremo passare in rassegna un certo numero di sigle del gergo “informatichese”. Dovete aver pazienza.

Cosa si intende per API, cioè “Application Program Interface”; cosa significa “Interfaccia di programmazione delle applicazioni”?

In termini semplici, una API è un insieme di protocolli e strumenti che consentono a due applicazioni di comunicare tra di loro.

Detto altrimenti, le API sono una forma di interoperabilità, ovvero la capacità di diverse applicazioni di lavorare insieme in modo efficiente e trasparente. Ciò consente alle applicazioni di scambiare dati, funzionalità e informazioni tra loro in modo efficiente.

Facciamo un esempio. Tra la nostra applicazione mobile forShop che può funzionare sul vostro tablet e le applicazioni che gestiscono i dati sui nostri server nella “nuvola” ci sono delle API che permettono il passaggio dei dati dallo schermo del tablet alle memorie dei server, e viceversa.
Richieste di dati ed erogazione dei medesimi passano sullo stesso canale offerto dalle API, che fungono, appunto, da “interfaccia”.

“Inter facies” è un’espressione latina e mi pare che possa indicare lo spazio interposto tra due “volti”, tra due “soggetti”, quello spazio che agevola la comunicazione tra di essi e che permette loro di collaborare ponendo in condivisione le qualità specifiche di ciascuno. Tornando al nostro esempio, potremmo dire che le API mettono in comunicazione l’agilità del dispositivo portatile con la potenza di calcolo e di gestione del server remoto.

Capite perché amo le API: con la forza del dialogo possiamo ottenere il meglio interconnettendo soggetti tecnologici differenti. Peace, love and API.

API: le regole per un dialogo

Affinché un dialogo sia efficace, per non essere un chiacchiericcio, del rumore di fondo, un motivo di incomprensione, ha bisogno di regole. Se questo vale per noi umani, che comunque dovremmo essere dotati di una certa elasticità e capacità di comprensione (dico: “dovremmo”…), figuriamoci per le macchine.

Quindi le API non sono semplicemente le funzionalità che implementano lo scambio di dati, ma sono anche la definizione di come deve avvenire il colloquio tra il soggetto che richiede i dati e il soggetto che li fornisce.

Come in diplomazia, anche qui si parla di protocolli, la definizione di un linguaggio comune compreso dalle due parti.

In genere chi implementa le API sulla macchina che fornirà i dati (o più in generale dei servizi) stabilisce anche come questi dati (o servizi) vanno richiesti. Ma può anche succedere il contrario: chi fruirà dei contenuti potrebbe essere anche colui che stabilisce come richiederli. Questo accade in genere quando la progettazione del sistema “fruitore/fornitore” (client/server) avviene all’interno della stessa organizzazione (Wallysoft, ad esempio).

L’importante è che si rispettino i protocolli di dialogo, che non si limitano a regolare come richiedere i dati, ma anche quali dati sono restituiti e come sono restituiti.

Elogio di HTTP

Non è sufficiente stabilire un protocollo per il dialogo, occorre anche stabilire un mezzo attraverso il quale dialogare. Per i dialoghi tra umani il mezzo può essere l’aria, attraverso la quale passano le onde sonore, oppure il sistema telefonico, o le reti telematiche, o anche il filo di corda teso tra due bicchierini di carta…

Per il dialogo implementato dalle API ovviamente si utilizzano le reti telematiche. In linea di principio il protocollo implementato dalle API potrebbe occuparsi di gestire tutti gli aspetti della comunicazione.

Però non è proprio il caso di reinventare la ruota per ogni nuovo progetto: esistono già protocolli di base per gestire le comunicazioni attraverso le reti telematiche, e così è saggio usare questi protocolli per veicolare i messaggi delle API.

In particolare c’è un protocollo, pensato per gestire lo scambio di informazioni tra ricercatori scientifici e implementato alla fine degli anni ’80 del secolo scorso, che è divenuto la base per la nostra quotidiana esperienza di navigazione tra i contenuti del Web. Si tratta di HTTP, HyperText Trasfer Protocol. Questo protocollo mette in comunicazione programmi informatici, nello specifico dei programmi “fruitori”, i web browser, che chiedono testi (ipertesti, cioè testi farciti di rimandi ad altri ipertesti) a programmi “fornitori”, i web server.

Come vedete è lo stesso schema che è implicato dalla tecnologia delle API: perché allora non far passare le richieste di dati attraverso HTTP? E infatti nella maggior parte dei casi si fa così…
Grande invenzione questo HTTP!

Json: la forma dei dati

Nel contesto della navigazione web generalmente i dati viaggiano tramite HTTP e sono “vestiti” nel formato HTML (HyperText Markup Language, “linguaggio di marcatura per ipertesti”). Nel contesto delle API, invece, si è trovato più agevole usare il formato Json, Javascript Object Notation, “rappresentazione degli oggetti al modo del linguaggio Javascript”. Non è l’unica rappresentazione di dati che si può usare, se ne possono usare altre, però è molto comoda (e in genere in Wallysoft è quella che usiamo).

API e grappini: i Webhook

Impariamo un’altra parola: webhook.

Avete presente i grappini dei pirati? Niente a che vedere con i grappini degli alpini: i grappini della marineria sono quelle piccole ancore a tre o quattro uncini legate all’estremità di cavi. Venivano lanciate verso le navi da abbordare per afferrarle e tenerle affiancate: un’immagine bellicosa, ma l’idea di agganciarsi a una risorsa per intercettare dei dati sta alla base del nome webhook (uncino web) scelto per quella tecnologia che potremmo definire come API inversa.

I webhook hanno la funzione di avvisare il dispositivo fruitore che qualche cosa, magari un dato, è stato modificato sul sistema fornitore. I webhook tengono agganciato il client al server, ma è il server a contattare il client in questo caso, proprio attraverso il webhook. Per questo possiamo pensarla come una API inversa. In genere poi il client reagirà utilizzando una API “normale” per ottenere dei dati a fronte della modifica che si è operata sul server.

Un caso concreto: l’eremita e i frati del convento

Concludiamo questo tour “acronimico” nel mondo delle API con una sorta di esempio.

C’è un eremita (il nostro dispositivo portatile) che vive a una certa distanza da un convento di frati (il server nel cloud). L’eremita gode di una grande autonomia rispetto al convento ma in qualche modo ne è dipendente, ad esempio per il cibo. Ci sarà allora un collegamento tra l’eremita e il convento, magari una piccola funicolare (la rete telematica). Sulla funicolare può viaggiare qualsiasi cosa (senza eccedere nel peso, ovviamente), ma tra eremita e frati si sarà stabilito un protocollo di base per l’interscambio dei cestini (l’equivalente del HTTP): se le cose non si fanno per bene si possono creare incomprensioni e conflitti anche tra quei sant’uomini che sono i frati e gli eremiti…

Nei cestini che viaggiano sulla funicolare, nel modo stabilito dagli accordi di base, ci sono dei bussolotti (corrisponderebbero al nostro formato Json). Questi bussolotti contengono le richieste dell’eremita che scendono verso il convento e il cibo che dal convento sale verso l’eremita (questi bussolotti, come Json, sono capaci di contenere un po’ di tutto). Questo scambio di bussolotti avviene secondo le API progettate, che regolano le richieste dell’eremita, l’elaborazione del cibo da parte del convento e la fornitura del cibo.

Supponiamo ora che di tanto in tanto il convento prepari un cibo speciale (magari un dolce) e che lo voglia condividere con l’eremita. Molto probabilmente ci sarà una campanella (il webhook) azionabile dal convento, che in questo modo avvisa l’eremita dell’evento: l’eremita si affretterà così a inviare un cestino con un apposito bussolotto verso il convento, e il bussolotto certamente non tornerà vuoto…

Bene, con questo edificante esempio mi congedo: spero tanto che questo tour nel meraviglioso mondo delle API sia stato di vostro gradimento. Alla prossima.