I servizi web sono sostanzialmente metodi che consentono la comunicazione tra due applicazioni o dispositivi sul World Wide Web. Le principali tecnologie in questo ambito sono il protocollo SOAP (Simple Object Access Protocol) e l’approccio architetturale REST (REpresentational State Transfer). Entrambi definiscono come creare le API necessarie per interfacciare la comunicazione tra più microservizi e applicazioni web. Vediamo in cosa consistono, quali sono le principali differenze e quali sono i criteri per orientare la scelta tra le due opzioni.
SOAP – Simple Object Access Protocol
SOAP (Simple Object Access Protocol) è un protocollo di comunicazione standard, ufficialmente gestito dal W3C, che consiste in una serie di regole e specifiche per lo scambio di messaggi XML. Per riuscire in questo intento SOAP impiega protocolli come l’HTTP (browser web), il SMTP (email), il TCP e molti altri. Nel caso del http, durante la navigazione sul web, emerge il sostanziale vantaggio nella possibilità di poter instradare la comunicazione attraverso firewall e proxy senza dover modificare il protocollo SOAP.
Rispetto ad alcune tecnologie middleware, come CORBA e ICE, SOAP risulta tuttavia più lento per via del formato XML impiegato nei messaggi di ritorno delle rispettive comunicazioni. Si tratta di un linguaggio di markup largamente supportato, ma non sempre ottimale sul piano delle performance.
Tuttavia, la standardizzazione del protocollo SOAP garantisce elevati livelli di conformità per quanto concerne l’acronimo ACID (atomicità, coerenza, isolamento e durata) oltre agli aspetti funzionali relativi all’affidabilità e alla sicurezza delle transazioni.
I servizi web garantiscono la comunicazione tra più applicativi web grazie a specifiche come:
- WS- addressing: creazione pacchetti con metadati all’interno delle intestazioni SOAP
- Web Services Description Language (WSDL): descrizione inizio e termine di un servizio web
- WS-ReliableMessaging: standardizzazione della gestione degli errori nei messaggi delle comunicazioni
- Web Service Security (WS-security): protezione e trasferimento dei messaggi mediante token univoci
REST – REpresentational State Transfer
REST (Representational State Transfer) è un set di principi architetturali con cui i dati possono essere trasmessi attraverso interfacce standardizzate, come il già citato protocollo HTTP nel caso dei browser web. REST è una tecnologia piuttosto moderna, che si basa si regole di design che consentono di creare servizi stateless, sempre più utilizzati anche nell’ambito dello sviluppo delle applicazioni web cloud native.
L’approccio REST permette agli sviluppatori di creare apposite API (API RESTful) che restituiscono i messaggi utilizzando un’ampia varietà di linguaggi, dall’HTML al JSON, che è di fatto il più diffuso. JSON è l’acronimo di JavaScript Object notification. La sua lettura non è limitata a JavaScript, ma è ottimizzato per essere fruito da un’ampia varietà di standard e tecnologie. Questo aspetto rende le API RESTful estremamente flessibili e semplici da configurazioni per connettere moltissime applicazioni web.
Nella condizione più ricorrente, le API RESTful soddisfano una serie di requisiti, coerenti con i principi architetturali a cui si ispirano:
- Architettura client / server
- Caching dei dati, per ottimizzare le connessioni client /server
- Comunicazione stateless, che non prevede il salvataggio lato server dei contenuti delle sessioni, che rimangono conservati sui client
- Struttura gerarchica nelle comunicazioni client / server, organizzata su più livelli
- Interfaccia uniforme per i vari componenti delle applicazioni, per trasferire le informazioni in maniera standardizzata, senza eccezioni specifiche.
Quest’ultimo aspetto è probabilmente ciò che distingue REST rispetto ad altri stili architettonici per la comunicazione dei componenti delle applicazioni Web.
SOAP vs REST: quale soluzione adottare
Oltre alla natura informatica, che vede SOAP come un protocollo e REST come un approccio architetturale, esistono varie differenze. Cerchiamo di individuarle grazie alle feature specifiche caratterizzano questi due popolari e diffusi servizi web.
Nel caso di REST, come abbiamo parzialmente già anticipato, le API RESTful consentono una comunicazione client / server di tipo stateless, del tutto indipendente dal caching delle precedenti sessioni. Al tempo stesso, non vi è un set di regole standardizzato per descrivere le interfacce dei servizi web REST, che risultano tuttavia semplici da integrare nei siti web esistenti, grazie alla notevole varietà di linguaggi utilizzati. Ciò rende possibile modernizzare le applicazioni web con un refactoring abbastanza moderato, senza dover riscrivere da zero interi componenti, agendo piuttosto sull’aggiunta di nuove funzionalità.
REST è dunque di base più moderno e semplice di SOAP, un protocollo la cui implementazione appare ben più radicata nel tempo, contribuendo a contribuire un vero e proprio punto di riferimento nell’ambito dei web services. Le API RESTful, grazie alle funzionalità stateless che sono in grado di supportare, vengono spesso impiegato nell’ambito di applicazioni moderne come quelle IoT, oltre a supportare la comunicazione tra le app sviluppate nei container stateless.
SOAP è per altri aspetti più completo, conforme rispetto a molti standard di usabilità e sicurezza, ma al tempo stesso certamente più complesso da sviluppare e gestire.
Data la loro differenza concettuale, prima ancora che tecnologica, non è possibile definire a priori se sia meglio utilizzare servizi web SOAP o REST, sebbene REST sia per certi versi favorito dalla sua più recente implementazione. Entrambe le architetture godono ormai di un’ampia tradizione e supporto da parte della community di sviluppatori di applicazioni web.
Se implementati in modo corretto sia i servizi web SOAP che REST sono adeguatamente scalabili e performanti. Non si tratta dunque di capire quale sia la tecnologia migliore, ma quale sia la più adatta rispetto allo scenario applicativo che si prospetta. La scelta si presenta pertanto di natura tecnologica, ma al tempo stesso culturale e spesso incline alle abitudini e all’esperienza dei team di sviluppo.
È evidente come la tradizione applicativa di SOAP e REST abbia risolto con successo le esigenze di aziende di tutte le dimensioni, dalla grande realtà enterprise alla PMI, supportando progetti che spaziano dal budget plurimilionario a semplici servizi di comunicazione per dispositivi IoT e sistemi embedded impiegati in produzione.
Quando gli sviluppatori si ritrovano nella condizione di dover scegliere la tipologia di servizi web con cui connettere i componenti delle applicazioni web, la scelta, oltre che dal background personale, dovrebbe essere orientata alla valutazione di alcuni particolari fattori, come la tipologia di client device da supportare. I servizi web REST si prestano ad esempio molto bene alle applicazioni per smartphone e tablet, mentre, almeno in certi casi, per le applicazioni enterprise, decisamente meno dinamiche nella loro evoluzione e decisamente esose in termini di affidabilità, la standardizzazione richiesta potrebbe giocare un punto a favore del SOAP.
Un altro aspetto da tenere in ferma considerazione deriva dall’analisi delle tecnologie e della cultura di sviluppo e gestione già presente nell’organizzazione entro cui si intende intervenire progettualmente, anche per valutare il livello di innovazione che si rende auspicabile introdurre, in una realtà più o meno consolidata.
