Le differenze tra API e messaggistica per la comunicazione tra le applicazioni

Phil Wilkins | Cloud Developer Evangelist, Oracle | dicembre 2022

I software devono poter interagire con altri software. A volte il software in una parte di un'applicazione deve richiedere servizi o scambiare dati con un'altra parte dell'applicazione. Oppure, un'applicazione deve richiedere servizi o scambiare dati con un'applicazione completamente diversa.

Esistono due meccanismi tipici utilizzati per questi tipi di comunicazione: le application programming interface (API) e la messaggistica.

A volte si crea confusione circa le differenze tra API e messaggistica. Questo perché i termini vengono spesso utilizzati in modo molto ambiguo. Lo stesso acronimo API ha un significato esplicito, ma per motivi che spiegheremo di seguito il termine ha assunto col tempo vari, diversi significati. Il termine messaggistica è spesso utilizzato in modo molto approssimativo per coprire quasi tutte le comunicazioni tra sistemi. Perciò, chiariamo cosa si intende veramente per API e messaggistica.

Una definizione dettagliata delle API

In generale, un'API è il contratto che definisce in che modo il software può ricevere e rispondere alle richieste di servizio. Tale contratto è fissato dagli sviluppatori del software.

Sembra semplice? Lo è, da un certo punto di vista. In pratica, il significato implicito dell'API può cambiare in base all'oggetto della conversazione. Se analizziamo l'acronimo, un'API riguarda l'interfaccia o il "contratto" mediante il quale un software può interagire con un altro software. A volte la conversazione su un'API si focalizza sulle sue definizioni architettoniche di alto livello; a volte è molto granulare, analizzando nel dettaglio le modalità specifiche con cui gli sviluppatori implementano l'API.

Alcuni libri e articoli sulle API per utilizzare un'analogia pensano a un'API come a una porta, con le caratteristiche dell'API che descrivono la porta. Ad esempio, potrebbe essere la porta di un negozio di alimentari che si apre automaticamente o la porta del caveau di una banca ultra-sicura. Il contratto di un'applicazione, ciò le caratteristiche della porta, dovrebbe aiutare a fare considerazioni come:

Che cosa fa l'API a un livello elevato? Seguendo la nostra analogia, si apre senza che l'ospite si fermi e tocchi qualcosa (la porta negozio di alimentari) o controlla l'accesso e protegge ciò che c'è dietro la porta (caveau della banca)?
Quali payload (dati trasmessi) dovranno supportare per consentire l'esecuzione del software? Ad esempio, il software potrebbe ricevere il numero di un conto bancario e un'autorizzazione di sicurezza e rispondere con il saldo del conto bancario.
Quali dati si intende scambiare per eseguire tale servizio? Ad esempio, è importante definire esattamente come sarebbero un numero di conto e un'autorizzazione di sicurezza validi e definire il contenuto della risposta. Qui i dettagli sono importanti; l'ambiguità può portare a errori.
Qual è l'indirizzo della porta? Questo in genere indica come viene formato l'universal resource identifier per la richiesta. Cioè, in che modo il richiedente si rivolge all'API?
Quali protocolli verranno utilizzati per comunicare? Questi possono variare da tecnologie note, come HTTP e FTP, a protocolli speciali, come STOMP e QUIC.
A quali termini e condizioni deve essere conforme l'utente API? Questi possono includere dettagli sulla cifratura, un limite alla frequenza con cui è possibile chiamare le API o meccanismi di riaddebito per i servizi commerciali.
Che promesse fa l'API? Fra queste ci possono essere garanzie a livello di servizio per l'API, in modo che una richiesta venga confermata o eseguita entro un periodo di tempo specifico.

Definire la messaggistica nello sviluppo delle applicazioni

Mentre con API si intendono i modi in cui i software inviano e ricevono le richieste di servizio, la messaggistica è il processo attraverso il quale si inviano informazioni da un sistema all'altro. La parola chiave è "processo".

Pensa a questo:

Con messaggistica si intende il processo di trasmissione di una parte di informazioni (il messaggio) dal richiedente al fornitore di servizi (spesso utilizzando una terza parte nota come broker).

Per utilizzare un'analogia, pensa a un'azienda che invia un messaggio di testo a un cliente. Il fornitore di servizi deve conoscere il numero di telefono del destinatario perché l'operatore telefonico possa consegnare il messaggio. Il contenuto, tuttavia, può essere qualsiasi cosa dal punto di vista dell'operatore. L'operatore non ha bisogno di sapere se il tuo messaggio di testo è in inglese, spagnolo, giapponese o se è semplicemente un'emoji.
Il termine messaggistica si riferisce a tutto quello che succede dietro le quinte perché il messaggio passi dal mittente al cliente.

Tu e il tuo cliente non avere bisogno di capire come funziona il processo di messaggistica; confidi solo nel fatto che gli operatori telefonici e i produttori di smartphone abbiano svolto correttamente il loro lavoro. E allo stesso modo, l'operatore non ha bisogno di capire il contenuto; deve semplicemente assicurarsi che venga consegnato alla persona giusta e che non risulti incomprensibile o distorto.

Vale la pena ribadire che la maggior parte delle piattaforme di messaggistica si indifferente rispetto al contenuto, purché rientri dentro i limiti della tecnologia. Per tornare alla nostra analogia, agli smartphone e agli operatori telefonici non importa se il tuo messaggio è in inglese o sotto forma di emoji.

Scopri ulteriori dettagli sulla composizione delle API, delle piattaforme API e della gestione delle API.

API e messaggistica operano in sinergia nei sistemi aziendali

I sistemi software aziendali sono costituiti da più processi eseguibili separatamente e, di conseguenza, richiedono una comunicazione tra processi (IPC, interprocess communication). Le comunicazioni qui possono essere complesse, avendo bisogno di molti back-and-forth con molte chiamate API e tanti dati rigorosamente formattati per eseguire una transazione. Tali transazioni devono essere attentamente orchestrate e completate nel giusto ordine per soddisfare un'esigenza aziendale.

Pensa, ad esempio, all'ordine di acquisto di un cliente. Il processo dovrà accedere al database dei clienti, eseguire delle query per il database dell'inventario, il sistema contabile, un sistema di generazione delle fatture e il sistema di addebito delle carte di credito, adeguare l'inventario e il conto cliente, creare una richiesta di warehouse e infine inviare una richiesta di spedizione: tutto questo dovrà essere fatto nell'ordine giusto e quindi completato nel modo corretto.

Storicamente, queste interazioni sono state eseguite utilizzando una qualche tipologia di storage condiviso, come un file system o un database. Tuttavia, in sistemi aziendali più moderni, i processi possono comunicare direttamente tra loro, accelerando il processo e rimuovendo i problemi (come quando le scorte per il tuo ordine sono già state allocate da ordini precedenti).

Comportamento sincrono e asincrono

La natura della nostra comunicazione può essere sincrona o asincrona. Con comunicazione sincrona si intende che tutte le parti coinvolte in una comunicazione devono essere presenti e in grado di inviare di nuovo. Ricorrendo alla nostro esempio di ordinazione, i sistemi coinvolti nei pagamenti elettronici devono essere disponibili per l'interazione in tempo reale. In altri casi, la comunicazione può essere asincrona, consentendo alle parti dei sistemi che vogliono comunicare di non essere presenti allo stesso momento. È così che funziona quando ci scriviamo e-mail. Affinché una comunicazione funzioni in modo asincrono, abbiamo bisogno di un intermediario che consenta la trasmissione di informazioni avanti e indietro.

Questi complessi sistemi di messaggistica aziendale sono disponibili sotto forma di diverse varietà o modelli:

Service bus. Il service bus funge da colla tra processi diversi ed esegue l'orchestrazione tra tali processi, come nella transazione complessa menzionata precedentemente. I sistemi service bus in genere incorporano funzionalità a valore aggiunto, come la possibilità di tradurre i contenuti da un formato all'altro (dall'inglese al francese nella nostra analogia di messaggi di testo), instradare i messaggi in base al contenuto del messaggio o prendere alcune decisioni in base allo stato della transazione complessa. Ad esempio, i task A e B possono essere eseguiti in parallelo; esegui il task C se il task B viene completato correttamente; se il task B non va a buon fine, esegui il task D; se il task D non va a buon fine, chiedi un'intervento umano.

La messaggistica service bus viene a volte descritta come una smart pipe, per via dell'aggiunta di funzionalità di intelligence in termini di instradamento e programmazione della messaggistica nel "pipe" tra provider e consumatori. Viene anche definita orchestrazione.

Il provider di messaggi chiama il service bus che fornisce un messaggio. Quindi il service bus prende il messaggio e lo indirizza ai consumatori. Durante l'instradamento, il messaggio può essere soggetto a una logica di trasformazione e filtro.

Un termine sinonimo di service bus è message bus. Quando queste tecnologie si stavano evolvendo per diventare soluzioni di service-oriented architecture (SOA), esistevano alcune differenze tra i service bus e message bus. Oggi, non ci sono differenze effettive. Difatti, il nome viene sempre più spesso accorciato al solo bus.
Servizi web:nel senso più ampio del termine, i servizi web rappresentano comunicazioni sincrone dirette tra due processi, in genere mediante i protocolli TCP e HTTP (o variazioni, ad esempio HTTPS e HTTP/2). Il consumatore e il client vengono realizzati come connessioni point-to-point (sebbene sia comune per l'end provider supportare più connessioni client allo stesso tempo). Potrebbero esserci proxy (da firewall di rete a gateway API e cache web) e intermediari di rete (switch e router) tra i due processi, ma né il fornitore né il consumatore ne saranno a conoscenza.
Il provider di messaggi comunica direttamente con il cliente. Il processo di trasmissione dipende dalla disponibilità di entrambe le parti.
Message broker:i message broker sono intermediari tra il provider e i messaggi e hanno punti in comune sia con i service bus che con i servizi web.

I broker si trovano tra il mittente e il destinatario dei messaggi e riceveranno il messaggio da comunicare per poi memorizzarlo fino a quando i destinatari non lo avranno consumato. Ciò significa che il messaggio può essere trasmesso senza doversi preoccupare della disponibilità immediata del destinatario. Di conseguenza, questo tipo di comunicazione è spesso descritto come asincrono o "fire and forget" perché si può essere certi che il messaggio sarò consegnato a un certo punto, purché il broker continui a funzionare.

La somiglianza con i servizi web deriva dal fatto che la connessione tra il client e il broker è rappresentata come una connessione point-to-point; il message broker è funzionalmente invisibile.

La somiglianza con un service bus deriva dal fatto che il broker offre un servizio a valore aggiunto, in quanto può trattenere i messaggi ricevuti fino a quando i destinatari non diventano disponibili. A differenza di un service bus più robusto, un message broker ha un'intelligence minima che va oltre il comprendere cose semplici, come sapere quali destinazioni potrebbero voler ricevere un determinato messaggio e cosa fare se la destinazione non consuma il messaggio in modo tempestivo.

Lo stile di comunicazione brokered viene definito come una dumb pipe. Poiché i broker hanno un'intelligenza minima, e c'è bisogno degli endpoint per capire cosa è necessario quando un messaggio deve essere inviato o ricevuto. Questo stile viene descritto come coreografia (in contrapposizione all'orchestrazione più intelligente di un service bus).

Il provider di messaggi invia il suo messaggio al broker. Il broker contiene trattiene il messaggio fino a quando il consumatore non ha richiesto un messaggio o non è in grado di ricevere il messaggio. Il fornitore non dipende dal consumatore.

Il ruolo dello streaming nella messaggistica aziendale

Lo streaming può essere visto come una forma di messaggistica piuttosto specializzata, sebbene alcune tecnologie di streaming possano supportare un elemento di elaborazione dati. Per streaming, in questo contesto, si intende l'atto di inviare un flusso continuo di eventi attraverso la tecnologia IPC alla stessa destinazione, indipendentemente dal fatto che i servizi web o i message broker implementino le comunicazioni. (Molto raramente sono coinvolti i service bus, perché ci sono troppi dati, che fluiscono troppo rapidamente, per essere necessaria l'intelligence extra di un service bus.)

Oltre al flusso continuo di dati, lo streaming di solito si aspetta una connettività quasi in tempo reale o a bassa latenza. Questo non sarà sorprendente se si considera il fatto che servizi come Netflix sono tradizionalmente chiamati video streaming. Di certo non vuoi che i contenuti video si fermino e si riavviino mentre nuovi bit di video vengono inviati dal provider o mentre un message broker trasforma i video da un formato all'altro.

Le tecnologie popolari per lo streaming di servizi web sono WebSockets, gli streaming GRPC e sottoscrizioni GraphQL. Quando si tratta di flussi di messaggistica mediati (utilizzando tecnologie come Kafka), a volte puoi sfruttare il funzionamento del broker per esaminare una "slice" degli eventi trasmessi. Ciò ti aiuta a raccogliere insight preziosi, tra cui informazioni sul flusso stesso: da qui il termine streaming analytics.

Sebbene la logica applicata negli streaming analytics possa essere sofisticata, il message broker non prende decisioni né manipola i messaggi. Per questa ragione il broker è ancora considerato inattivo. Questi tipi di funzionalità di streaming analytics vengono spesso implementate con tecnologie come Kafka Streams.

Standard del settore per API e messaggistica

Le API e i sistemi di messaggistica sono semplici da descrivere, ma molto complessi nei dettagli e nelle caratteristiche tecniche. Non c'è semplicemente spazio per l'ambiguità, il che porta ad un grande bisogno di standard e documentazione di settore accurata e idealmente dell'applicazione migliore di questi standard.

Questa è stata un'area di sviluppo, in particolare per le API, da oltre dieci anni. Il settore ha adottato la specifica OpenAPI per le API basate su REST, che sono una tipologia di servizi web e probabilmente i tipi più comuni di API utilizzate nei software aziendali moderni.

Grazie alle API (e allo streaming) esistono diversi standard aggiuntivi per la definizione e la descrizione degli aspetti dei messaggi e della loro trasmissione. Fra questi ci sono i buffer di protocollo (chiamati anche Protobuf e utilizzati con gRPC) e, più di recente, GraphQL, JSON Schema e YAML.

Nel dominio della messaggistica asincrona, negli ultimi anni si è tentato di aggregarsi intorno a una definizione chiamata AsyncAPI, che ha adattato le idee provenienti da OpenAPI e da altri standard in evoluzione per soddisfare i numerosi requisiti di messaggistica.

Le moderne applicazioni distribuite vengono implementate come una raccolta di servizi che sono parti separate di software, a volte in esecuzione sugli stessi server, a volte no. Le API consentono a queste parti di software di parlare tra loro per richiedere servizi o per scambiare informazioni. I sistemi di messaggistica offrono l'infrastruttura per agevolare le comunicazioni asincrone e forniscono middlemen intelligenti per le chiamate API, che possono essere molto semplici (il modo in cui funzionano i messaggi dello smartphone) o estremamente complesse (ad esempio, l'orchestrazione per transazioni aziendali complesse in più fasi). Per non parlare dei servizi distribuiti che comunicano direttamente tra loro mediante le API. Fortunatamente, tecniche e standard in evoluzione consentono l'uso delle API in ogni ambito, dalle chiamate ai database agli streaming media. Inoltre, queste API e questi standard di messaggistica continuano ad evolversi e ad avanzare, rendendo più rapida, semplice e sicura la transizione alle moderne architetture software distribuite.