Il termine API, acronimo di Application Programming Interface (interfaccia di programmazione delle applicazioni), indica un insieme di definizioni e protocolli per la creazione e l'integrazione di applicazioni software.

Le API permettono ai tuoi prodotti o servizi di comunicare con altri prodotti o servizi, anche se non sai come sono stati implementati, semplificando così lo sviluppo delle app e consentendo un netto risparmio di tempo e denaro. Durante la progettazione di nuovi strumenti e prodotti, o la gestione di quelli esistenti, le API garantiscono flessibilità, semplificano la progettazione, l'amministrazione e l'utilizzo, oltre a offrire opportunità di innovazione.

Talvolta vengono concepite come una forma di contratto, con una documentazione che rappresenta un accordo tra le parti: se la parte A invia una richiesta remota strutturata in un determinato modo, il software della parte B risponderà in un altro modo determinato.

I vantaggi delle API

Semplificando l'integrazione dei nuovi componenti applicativi nell'architettura esistente, le API promuovono la collaborazione tra team amministrativi e IT. Per restare competitive e rispondere ai costanti mutamenti dei mercati digitali, in cui nuovi concorrenti possono rivoluzionare un intero settore con una nuova app, le aziende devono adattarsi rapidamente e supportare lo sviluppo e il deployment di servizi innovativi. Lo sviluppo di applicazioni cloud native, basato sul collegamento di un'architettura applicativa di microservizi attraverso le API, consente di accelerare la velocità di sviluppo.

Grazie alle API è possibile collegare con facilità l'infrastruttura mediante lo sviluppo di app cloud native, nonché condividere i dati con i clienti e con altri utenti esterni. Le API pubbliche sono utilissime perché, oltre a semplificare ed espandere le modalità di connessione fra la tua azienda e i suoi partner, permettono anche di monetizzare i dati, come avviene ad esempio con l'API di Google Maps.

Prova a pensare a un distributore di libri. L'azienda potrebbe offrire ai clienti un'app cloud che permette ai commessi nelle librerie di verificare la disponibilità dei libri. Un'app di questo tipo potrebbe essere molto costosa da sviluppare, vincolata a una piattaforma, richiedere lunghi tempi di sviluppo e imporre interventi di manutenzione regolari.

In alternativa, il distributore può fornire un'API per controllare la disponibilità in magazzino. Questo approccio offre diversi vantaggi.

• Consentire ai clienti di accedere ai dati tramite un'API aiuta a raccogliere le informazioni in un inventario unificato.
• Il distributore può apportare modifiche ai sistemi di distribuzione interni senza impatto sui clienti, a condizione che il comportamento dell'API non subisca modifiche.
• Con un'API pubblicamente disponibile, gli sviluppatori che lavorano per il distributore, i rivenditori e i provider di altri servizi possono sviluppare un'app che aiuti i consumatori a trovare i libri che stanno cercando, incrementando le vendite o altre opportunità di business.

In breve, le API consentono l'accesso alle tue risorse mantenendo sicurezza e controllo. Sarai tu a decidere come e a chi concedere l'accesso. Per garantire la sicurezza delle API è necessario gestirle efficacemente, avvalendosi di un gateway API. Per connettersi alle API e creare applicazioni che usano i dati o le funzioni esposte da queste ultime, è possibile utilizzare una piattaforma di integrazione distribuita capace di connettere ogni singolo elemento, inclusi i sistemi esistenti e la Internet of Things (IoT).

L'esposizione delle API ai partner o al pubblico consente di:

• Creare nuovi canali di reddito o espandere quelli esistenti.
• Espandere la copertura del tuo brand.
• Facilitare l'apertura all'innovazione o l'incremento dell'efficienza grazie allo sviluppo e alla collaborazione con l'esterno.

In che modo le API riescono a ottenere questi risultati?

Torniamo all'esempio del distributore di libri.

Uno dei partner dell'azienda sviluppa un'app che aiuta i clienti a trovare i libri sugli scaffali della libreria. Questa esperienza migliorata aumenta il numero di acquirenti nel negozio (il cliente del distributore) ed espande un canale di reddito già esistente.

Una terza parte utilizza forse un'API pubblica per sviluppare un'app che consente di acquistare i libri direttamente dal distributore anziché dalla libreria. Ciò apre un nuovo canale di reddito per il distributore.

La condivisione delle API, sia con partner selezionati che con chiunque altro, può avere effetti positivi. Ogni partnership estende il riconoscimento del marchio ben oltre l'impegno del team che si occupa delle operazioni di marketing. Esporre la tecnologia a chiunque, come accade con un'API pubblica, incoraggia gli sviluppatori a creare un sistema di app incentrato sull'API. Maggiore è il numero di persone che utilizzano la tecnologia condivisa, maggiori le opportunità di business.

Rendere pubblica una tecnologia può portare a risultati nuovi e inattesi, che possono rivoluzionare interi settori. Per il nostro distributore di libri, le nuove aziende (ad esempio un provider che offre servizi di noleggio libri) potrebbero cambiare sostanzialmente il modello aziendale. Le API condivise con i partner e le API pubbliche permettono di beneficiare dello sforzo creativo di una comunità più ampia rispetto al team di sviluppatori interni. Con nuove idee in arrivo da tutte le direzioni, le aziende devono essere sempre consapevoli dei cambiamenti che avvengono nei settori di pertinenza, per essere pronte a reagire. In questo senso, le API sono d'aiuto.

Le API sono state introdotte agli albori dell'era informatica, molto prima della comparsa dei personal computer. A quell'epoca, un'API era in genere utilizzata come libreria per un sistema operativo. Era a livello locale rispetto al sistema in cui operava, sebbene a volte passasse messaggi tra mainframe. Dopo circa 30 anni, le API sono emerse dai loro ambienti locali. Nei primi anni 2000 si trasformarono in un'importante tecnologia per l'integrazione remota dei dati.

Le API remote sono concepite per interagire attraverso una rete di comunicazione. Si chiamano API remote perché le risorse gestite da tali API si trovano all'esterno del computer che invia la richiesta. Poiché il canale di comunicazione maggiormente utilizzato è Internet, quasi tutte le API vengono progettate in base agli standard web. Non tutte le API remote sono API web, ma possiamo affermare che le API web sono remote.

Queste ultime utilizzano in genere l'HTTP per richiedere messaggi e fornire una definizione della struttura dei messaggi di risposta. I messaggi di risposta assumono in genere la forma di file XML o JSON, due formati diffusi perché presentano i dati in modo da consentire alle altre app di gestirli facilmente.

Vista la continua diffusione delle API web, è stato sviluppato un protocollo specifico con lo scopo di standardizzare lo scambio delle informazioni, denominato Simple Object Access Protocol, o protocollo SOAP. Le API progettate con il protocollo SOAP usano il linguaggio XML come formato del messaggio e ricevono le richieste tramite HTTP o SMTP. Il protocollo SOAP facilita la condivisione delle informazioni per le app eseguite su ambienti diversi o scritte in linguaggi differenti.

È stata introdotta anche la specifica Representational State Transfer (REST). Le API web che rispettano i vincoli architetturali REST vengono definite API RESTful. La differenza tra REST e SOAP è sostanziale: il SOAP è un protocollo, mentre il REST è un tipo di architettura e ciò implica l'assenza di uno standard ufficiale per le API web RESTful. Come indicato nella tesi di Roy Fielding "Architectural Styles and the Design of Network-based Software Architectures," le API sono definibili RESTful se rispettano i sei vincoli di un sistema RESTful:

• Architettura client-server: l'architettura REST è costituita da client, server e risorse e gestisce le richieste tramite il protocollo HTTP.
• Statelessness: nessun contenuto client è archiviato nel server tra le richieste. Le informazioni relative allo stato della sessione sono invece contenute nel client.
• Supporto cache: il caching può eliminare la necessità di alcune interazioni client-server.
• Sistema a livelli: le interazioni client-server possono essere mediate da livelli aggiuntivi, i quali possono offrire altre funzionalità, come bilanciamento del carico, condivisione della cache o sicurezza.
• Codice on demand (opzionale): i server possono ampliare la funzionalità di un client trasferendo del codice eseguibile.
• Interfaccia uniforme: è il vincolo principale per la progettazione di API RESTful e prevede 4 aspetti:
  • Identificazione delle risorse nelle richieste: le risorse vengono identificate nelle richieste e vengono distinte dalle rappresentazioni restituite al client.
  • Manipolazione delle risorse tramite le rappresentazioni: i client ricevono file che rappresentano le risorse e che devono contenere le informazioni necessarie per consentirne la modifica o l'eliminazione.
  • Messaggi autodescrittivi: ogni messaggio restituito a un client contiene le informazioni necessarie per descrivere come il client deve elaborare l'informazione.
  • Ipermedia come motore dello stato dell'applicazione: accedendo alla risorsa, il client REST deve poter individuare, attraverso hyperlink, tutte le altre azioni disponibili al momento.

Benché sembrino numerosi, questi vincoli sono molto più semplici rispetto a un protocollo prescritto e, proprio per questo, le API RESTful sono molto più diffuse dei metodi SOAP.

Negli ultimi anni, la specifica OpenAPI si è imposta come standard comune per la definizione delle API REST, poiché consente agli sviluppatori di realizzare interfacce API REST indipendenti dal linguaggio e facilmente comprensibili agli utenti.

Un altro standard emergente è GraphQL, un linguaggio di interrogazione e runtime lato server nato come alternativa a REST. GraphQL è progettato per fornire ai client esattamente ed esclusivamente i dati di cui hanno bisogno. Nato come alternativa a REST, GraphQL consente agli sviluppatori di costruire, con una singola chiamata API, richieste che contengono dati provenienti da più sorgenti.

Le API remote vengono utilizzate soprattutto nelle architetture Service-Oriented Architecture (SOA) e nelle architetture basate sui microservizi. SOA, il meno recente tra i due approcci, nasce come miglioramento delle app monolitiche. Mentre una singola app monolitica esegue tutto, alcune funzioni possono essere fornite da app diverse con basso accoppiamento tramite uno schema di integrazione, ad esempio un Enterprise Service Bus (ESB).

Sebbene il SOA sia, sotto molti punti di vista, più semplice rispetto a un'architettura monolitica, implica il rischio di modifiche a cascata nell'intero ambiente qualora non siano chiare le interazioni tra componenti. Questa ulteriore difficoltà ripropone alcuni dei problemi che il SOA puntava a risolvere.

Le architetture di microservizi sono simili agli schemi SOA per quel che riguarda l'impiego di servizi specializzati a basso accoppiamento, ma scompongono ulteriormente le architetture tradizionali. I servizi nell'ambito delle architetture di multiservizi adottano un framework di messaggistica comune, come le API RESTful. Utilizzano queste ultime per comunicare tra loro senza complesse transazioni di conversione dei dati o livelli di integrazione aggiuntivi. L'impiego delle API RESTful agevola e promuove la distribuzione più rapida di nuove funzioni e aggiornamenti. Ogni servizio è distinto. Un servizio può essere sostituito, migliorato o messo da parte senza effetti sugli altri servizi dell'architettura. Questa architettura leggera consente di ottimizzare le risorse distribuite o cloud e supporta la scalabilità dinamica dei singoli servizi.

Un webhook è una funzione di callback HTTP che consente una semplice comunicazione basata sugli eventi fra 2 API. Utilizzati da moltissime app web per la ricezione di piccole quantità di dati da altre app, i webhook possono essere usati anche per attivare flussi di lavoro di automazione negli ambienti GitOps.

I webhook vengono spesso chiamati anche API inverse o API push, perché affidano la responsabilità della comunicazione al server anziché al client. Non è il client a inviare le richieste HTTP di dati per poi attendere la risposta del server, ma è il server che invia al client una singola richiesta HTTP POST appena i dati sono disponibili. Nonostante il nome, in realtà i webhook non sono API, ma vengono utilizzati insieme a queste ultime. Infatti, un'applicazione può utilizzare un webhook solo se dispone di un'API.