Cos'è un'API?

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.

Un'API permette al tuo prodotto o servizio di comunicare con altri prodotti e servizi senza dover sapere come vengono implementati. Questo può semplificare lo sviluppo delle app e far risparmiare tempo e denaro. Quando sviluppi nuovi strumenti e prodotti, o gestisci quelli esistenti, le API offrono maggiore flessibilità, semplificano la progettazione, l'amministrazione e l'utilizzo e aprono nuove opportunità di innovazione.

Talvolta le API vengono considerate come contratti, in cui la documentazione definisce l'accordo tra le parti: se la parte 1 invia una richiesta remota strutturata in un determinato modo, il software della parte 2 risponderà di conseguenza.

Semplificando l'integrazione di nuovi componenti applicativi in un'architettura esistente, le API promuovono la collaborazione tra azienda e team IT. Le esigenze aziendali cambiano rapidamente per adattarsi a mercati digitali in continua evoluzione, dove nuove aziende concorrenti possono trasformare un intero settore con una sola app. Per restare competitivi, è importante favorire lo sviluppo e il deployment rapidi di servizi innovativi. Lo sviluppo di applicazioni cloud native è un modo concreto per aumentare la rapidità con cui vengono create e distribuite e si basa sul collegamento, tramite API, dei componenti di un'architettura applicativa a microservizi.

Le API semplificano il collegamento della tua infrastruttura nell'ambito dello sviluppo di app cloud native e consentono anche di condividere i tuoi dati con clienti e altri utenti esterni. Le API pubbliche offrono un valore aziendale unico perché possono semplificare la collaborazione con i partner, ampliarne le possibilità e, potenzialmente, consentire di monetizzare i dati (l'API di Google Maps ne è un esempio noto).

Prendiamo, ad esempio, un'azienda che distribuisce libri. Il distributore potrebbe mettere a disposizione dei propri clienti un'app cloud che consenta al personale delle librerie di verificare la disponibilità dei libri. Lo sviluppo di questa app potrebbe essere costoso, vincolato alla piattaforma e richiedere tempi lunghi, oltre a una manutenzione continua.

In alternativa, il distributore di libri potrebbe fornire un'API per verificare la disponibilità dei titoli. Questo approccio offre diversi vantaggi:

• Consentire ai clienti di accedere ai dati tramite un'API li aiuta a riunire in un unico punto le informazioni relative all'inventario.
• Il distributore può modificare i propri sistemi interni senza ripercussioni sui clienti, purché il comportamento dell'API rimanga invariato.
• Con un'API disponibile al pubblico, gli sviluppatori del distributore, delle librerie o di terze parti potrebbero creare un'app per aiutare i clienti a trovare i libri che cercano, generando così un aumento delle vendite o altre opportunità di business.

In sostanza, le API permettono di rendere accessibili le tue risorse senza rinunciare a sicurezza e controllo. Sta a te decidere in che modo consentire l'accesso e a chi. Per garantire la sicurezza delle API è fondamentale gestirle correttamente, anche attraverso l'uso di un gateway API. Una piattaforma di integrazione distribuita consente di collegarsi alle API e creare applicazioni che ne utilizzano dati e funzionalità, mettendo in comunicazione qualsiasi elemento, inclusi i sistemi legacy e l'Internet of Things (IoT).

Mettere le API a disposizione dei partner o del pubblico può:

• Creare nuovi canali di fatturato o ampliare quelli esistenti.
• Aumentare la visibilità del brand.
• Favorire l'innovazione aperta o una maggiore efficienza attraverso lo sviluppo e la collaborazione con soggetti esterni.

Sembra fantastico, vero? Ma come fanno le API a offrire tutti questi vantaggi?

Torniamo all'esempio dell'azienda che distribuisce libri.

Supponiamo che uno dei partner dell'azienda sviluppi un'app che aiuta le persone a trovare i libri sugli scaffali delle librerie. Questo miglioramento dell'esperienza attira più acquirenti in libreria, ossia presso il cliente del distributore, e amplia un canale di fatturato già esistente.

O magari una terza parte potrebbe utilizzare un'API pubblica per sviluppare un'app che consenta di acquistare libri direttamente dal distributore, anziché in negozio, aprendo così un nuovo canale di fatturato per il distributore stesso.

Condividere le API con partner selezionati o con il pubblico può avere effetti positivi. Ogni partnership contribuisce ad ampliare la notorietà del brand oltre ciò che l'azienda potrebbe ottenere con le sole attività di marketing. Aprire una tecnologia a tutti, come avviene con un'API pubblica, favorisce la creazione da parte degli sviluppatori di un ecosistema di app attorno all'API. Più persone utilizzano la tua tecnologia, maggiori sono le probabilità che scelgano di rivolgersi alla tua azienda.

Mettere una tecnologia a disposizione di tutti può generare esiti nuovi e imprevisti, che in alcuni casi trasformano interi settori. Nel caso del nostro distributore di libri, nuove attività, come un servizio di prestito di libri, potrebbero trasformare profondamente il suo modello di business. Le API per partner e le API pubbliche consentono di sfruttare la creatività di una community più ampia rispetto al team interno di sviluppatori. Le nuove idee possono arrivare da qualsiasi parte e le aziende devono saper cogliere i cambiamenti del mercato ed essere pronte ad agire di conseguenza. Le API possono fare molto.

Le API sono nate agli albori dell'informatica, molto prima dei personal computer. All'epoca, venivano utilizzate principalmente come librerie per i sistemi operativi. Erano quasi sempre confinate ai sistemi su cui operavano, anche se a volte scambiavano messaggi tra mainframe. Dopo quasi 30 anni, hanno superato i confini degli ambienti locali. All'inizio degli anni 2000, le API hanno assunto un ruolo sempre più importante nell'integrazione di dati da remoto.

Le API remote sono progettate per comunicare tramite una rete. Per remote si intende che le risorse su cui opera l'API si trovano esternamente al computer che invia la richiesta. Dal momento che Internet è la rete di comunicazione più utilizzata, la maggior parte delle API è progettata in base agli standard web. Non tutte le API remote sono API web, ma tutte le API web possono essere considerate remote.

In genere le API web utilizzano HTTP per inviare le richieste e specificano la struttura dei messaggi di risposta, che in genere sono file XML o JSON, due formati diffusi perché presentano i dati in modo da consentire alle altre app di gestirli facilmente.

Con la diffusione delle API web, è stata sviluppata una specifica di protocollo per standardizzare lo scambio di informazioni: Simple Object Access Protocol, più comunemente noto come SOAP. Le API progettate con SOAP utilizzano XML come formato dei messaggi e ricevono le richieste tramite HTTP o SMTP. SOAP facilita lo scambio di informazioni tra app eseguite in ambienti diversi o scritte in linguaggi diversi.

Un'altra specifica è Representational State Transfer (REST). Le API web che rispettano i vincoli architetturali REST vengono chiamate API RESTful. REST si differenzia da SOAP per un aspetto fondamentale: SOAP è un protocollo, mentre REST è uno stile architetturale. Ciò significa che non esiste uno standard ufficiale per le API web RESTful. Come definito nella tesi di Roy Fielding "Architectural Styles and the Design of Network-based Software Architectures", le API sono RESTful finché rispettano i sei vincoli fondamentali di un sistema RESTful:

• Architettura client-server: l'architettura REST è composta da client, server e risorse e gestisce le richieste tramite HTTP.
• Statelessness: tra una richiesta e l'altra, sul server non viene memorizzato alcun contenuto del client. Le informazioni sullo stato della sessione vengono invece mantenute dal client.
• Cache: l'uso della cache può eliminare la necessità di alcune interazioni tra client e server.
• Sistema a livelli: le interazioni tra client e server possono essere mediate da livelli aggiuntivi, che possono offrire funzionalità come bilanciamento del carico, cache condivise o sicurezza.
• Codice on demand (facoltativo): i server possono estendere le funzionalità di un client trasferendo codice eseguibile.
• Interfaccia uniforme: questo vincolo è fondamentale nella progettazione delle API RESTful e comprende quattro aspetti:
  • Identificazione delle risorse nelle richieste: le risorse vengono identificate nelle richieste e sono distinte dalle rappresentazioni restituite al client.
  • Manipolazione delle risorse tramite rappresentazioni: i client ricevono file che rappresentano le risorse. Queste rappresentazioni devono contenere informazioni sufficienti per consentirne la modifica o l'eliminazione.
  • Messaggi autodescrittivi: ogni messaggio restituito a un client contiene informazioni sufficienti per indicare al client come elaborarne il contenuto.
  • Ipermedia come motore dello stato dell'applicazione: dopo aver effettuato l'accesso a una risorsa, il client REST dovrebbe poter individuare tramite collegamenti ipertestuali tutte le altre azioni disponibili in quel momento.

Questi vincoli possono sembrare numerosi, ma restano molto più semplici da gestire rispetto a un protocollo rigido. Per questo le API RESTful sono sempre più diffuse rispetto a SOAP.

Negli ultimi anni, la specifica OpenAPI si è affermata come standard comune per la definizione delle API REST. OpenAPI definisce un approccio indipendente dal linguaggio che consente agli sviluppatori di creare interfacce API REST facili da comprendere, limitando la necessità di ricorrere a tentativi.

Un altro standard API che ha preso piede è GraphQL, un linguaggio di query e runtime lato server che rappresenta un'alternativa a REST. GraphQL è progettato per fornire ai client esattamente i dati richiesti, senza aggiungerne altri. Come alternativa a REST, GraphQL consente agli sviluppatori di creare richieste che recuperano dati da più sorgenti con un'unica chiamata API.

Scopri di più su SOAP e REST

I due approcci architetturali che fanno maggior uso di API remote sono la Service-Oriented Architecture (SOA) e l'architettura di microservizi. SOA, il più datato dei due, è nato come evoluzione delle app monolitiche. Mentre un'unica app monolitica svolge tutte le funzioni, alcune possono essere gestite da app diverse, a basso accoppiamento, collegate tramite un modello di integrazione come un Enterprise Service Bus (ESB).

Sebbene sotto molti aspetti la SOA sia più semplice di un'architettura monolitica, comporta il rischio di modifiche a cascata nell'intero ambiente se le interazioni tra i componenti non sono ben chiare. Questa complessità aggiuntiva reintroduce alcuni dei problemi che la SOA puntava a risolvere.

Le architetture di microservizi condividono con la SOA l'uso di servizi specializzati a basso accoppiamento, ma frammentano ulteriormente le architetture tradizionali. I servizi di un'architettura di microservizi utilizzano un framework di messaggistica comune, come le API RESTful, per comunicare tra loro senza dover ricorrere a complesse conversioni dei dati o a livelli di integrazione aggiuntivi. L'uso delle API RESTful consente, e persino favorisce, una distribuzione più rapida di nuove funzionalità e aggiornamenti. Ogni servizio è indipendente e può essere sostituito, migliorato o rimosso senza ripercussioni sugli altri servizi dell'architettura. Questa architettura leggera contribuisce a ottimizzare le risorse distribuite o cloud e supporta la scalabilità dinamica dei singoli servizi.

Scopri di più sulle SOA

Un webhook è una funzione di callback basata su HTTP che consente una comunicazione leggera e basata su eventi tra due API. Funzionali a numerose app web per la ricezione di piccole quantità di dati da altre app, possono anche attivare flussi di lavoro di automazione in ambienti GitOps.

I webhook vengono spesso chiamati anche API inverse o API push, perché fanno ricadere la responsabilità della comunicazione sul server e non sul 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 non appena i dati sono disponibili. Nonostante i nomi con cui vengono definiti, 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. 

Scopri di più sui webhook

Il Model Context Protocol (MCP) e le API consentono entrambi di collegare e far comunicare sistemi distinti. Le funzionalità degli MCP si basano sulle API e non esisterebbero senza di esse. 

Le due tecnologie si differenziano per il funzionamento e gli scopi per cui sono state create:

• L'MCP collega i modelli linguistici a strumenti e dati esterni, rendendo possibili flussi di lavoro che si adattano e improvvisano in tempo reale. 
• I flussi di lavoro delle API tradizionali seguono regole prestabilite. Una volta collegati due sistemi, possono eseguire solo una serie specifica di azioni programmate da uno sviluppatore.

Scopri di più su MCP e API