Integrazione

Cosa sono le API?

Un'interfaccia di programmazione delle applicazioni (API) è un set di strumenti, definizioni e protocolli per la compilazione di software applicativi. Consente ai tuoi prodotti o servizi di comunicare con altri prodotti o servizi senza sapere come vengono implementati. Le API possono semplificare lo sviluppo delle app, con un conseguente risparmio di tempo per gli sviluppatori, e di denaro per le aziende. 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.

Immagina, ad esempio, un'azienda che distribuisce libri. Il distributore potrebbe offrire ai suoi clienti un'app 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. È 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).

Esistono tre diversi approcci ai criteri di rilascio delle API.

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.

Innovare con le API

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.

Come è possibile ottenere tutti questi vantaggi attraverso le API? Come riescono le API 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.

La storia delle API in breve

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.

API remote

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.


Cosa è stato fatto per migliorare le API?

Le API si sono evolute in API web, ormai molto diffuse. Nel tempo sono stati fatti molti tentativi per semplificarne il design e renderne l'implementazione più utile.

Protocolli SOAP e REST

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 REST, Representational State Transfer. 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.

SOA e architettura di microservizi a confronto

I due approcci architetturali che maggiormente utilizzano le API remote sono l'architettura SOA (Service-Oriented Architecture) 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 linguaggio 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 l'erogazione più rapida di nuove funzioni e aggiornamenti. Ogni servizio è discreto. 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.

APIs and Red Hat

Red Hat gives you modular, lightweight, and comprehensive API solutions that are open source, open standards, and available on-premise or in the cloud.

Platform

Integrate your diverse IT assets with a distributed, flexible integration platform. Red Hat Fuse provides the infrastructure and tooling you need to integrate everything.

Platform

Manage your APIs for internal and external users with a platform that makes APIs easy to share, secure, distribute, control, and monetize.

Le API si prestano a molti altri utilizzi