Jump to section

Cos'è un'API?

Copia URL

API è l'abbreviazione di interfaccia di programmazione delle applicazioni (application programming interface), ovvero un insieme di definizioni e protocolli per la creazione e l'integrazione di software applicativi.

Le API permettono ai tuoi prodotti o servizi di comunicare con altri prodotti o servizi senza che sia necessario sapere come vengono implementati, semplificando così lo sviluppo delle app e consentendo un netto risparmio di tempo e denaro. Durante la creazione di nuovi strumenti e prodotti o la gestione di quelli esistenti, le API offrono flessibilità, semplificano la progettazione, l'amministrazione e l'utilizzo, e garantiscono 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.

Le API, semplificando l'integrazione di nuovi componenti applicativi in un'architettura esistente, promuovono la collaborazione tra azienda e team 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 estremamente preziose poiché oltre a semplificare ed espandere il modo in cui la tua azienda si collega con i tuoi partner, permettono anche di monetizzare i dati (basti pensare all'API di Google Maps).

Immagina, ad esempio, un'azienda che distribuisce libri. Il distributore potrebbe offrire ai suoi clienti un'app cloud che consente ai commessi delle librerie di controllare la disponibilità dei libri. L'app potrebbe essere però costosa da sviluppare, vincolata a una piattaforma, esigente in termini di tempi di sviluppo e soggetta a manutenzione costante.

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. La sicurezza della API dipende dalla loro gestione, che include l'utilizzo di un gateway API. È possibile connettersi alle API e creare applicazioni che usano i dati o le funzionalità esposte dalle API tramite una piattaforma di integrazione distribuita in grado di connettere ogni elemento, inclusi i sistemi esistenti e l'Internet of Things (IoT).

Privato

L'API è destinata solo a un utilizzo interno. Questo approccio offre alle aziende un controllo delle API ottimale.

Partner

L'API è condivisa tra specifici partner aziendali. Questo approccio può fornire flussi di reddito aggiuntivi, senza compromettere la qualità.

Pubblico

L'API è disponibile a chiunque. Questo approccio consente a terze parti di sviluppare app che interagiscono con l'API e che possono rappresentare una fonte di innovazione.

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.

L'avvento delle API risale agli albori dell'era dell'informazione, ben prima 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 tramite una rete di comunicazione. Si chiamano API remote, perché le risorse gestite dall'API sono esterne al computer che invia la richiesta. Poiché il canale di comunicazione più diffusamente utilizzato è Internet, la maggior parte delle API è progettata in base a 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.

Di pari passo alla diffusione delle API web è stato sviluppato un protocollo specifico con lo scopo di uniformare lo scambio delle informazioni, noto come 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.

Un'altra specifica è nota come Representational State Transfer (REST). Le API web che rispettano i vincoli architettonici REST vengono definite API RESTful. La differenza tra REST e SOAP è sostanziale: il SOAP è un protocollo mentre il REST è uno stile architetturale, 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 ciò influisce sulla maggiore frequenza d'uso delle API RESTful rispetto ai metodi SOAP.

Negli ultimi anni, la specifica OpenAPI ha avuto una grande diffusione come standard comune per la definizione di API REST. La specifica rappresenta per gli sviluppatori una modalità indipendente dal linguaggio con la quale realizzare interfacce API REST comprensibili agli utenti senza eccessive complessità.

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 ottenere richieste contenenti dati provenienti da più sorgenti, in una singola chiamata API.

I due approcci architetturali che maggiormente utilizzano le API remote sono l'architettura Service-Oriented Architecture (SOA) e l'architettura di 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 aiuta a ottimizzare le risorse distribuite o cloud e supporta la scalabilità dinamica dei singoli servizi.

Approfondisci

Articolo

Cos'è un'API?

API è l'abbreviazione di interfaccia di programmazione delle applicazioni (application programming interface), un insieme di definizioni e protocolli per la creazione e l'integrazione di software applicativi.

Articolo

Cos'è un gateway API?

Un gateway API è uno strumento di gestione delle interfacce di programmazione delle applicazioni (API) che si situa tra un client e una raccolta di servizi back end.

Articolo

Perché rivolgersi a Red Hat per la gestione delle API

Le soluzioni API di Red Hat rendono l'infrastruttura informatica agile e riutilizzabile, anche grazie all'interfaccia di gestione che consente di misurare e monitorare tecnologie e processi sfruttandone la scalabilità.

Scopri di più sulle API

Prodotti

Red Hat 3scale API Management

Un'infrastruttura che consente di condividere, distribuire, controllare e monetizzare le interfacce di programmazione delle applicazioni (API).

Risorse

Resoconto analitico

Red Hat Integration aiuta le imprese a ottimizzare le prestazioni delle applicazioni e i risultati di business.

Ebook

Agile integration: un modello per l'architettura enterprise.

Illustration - mail

Ricevi contenuti simili

Iscriviti a Red Hat Shares, la nostra newsletter gratuita.