All'inizio della guida RESTful abbiamo distinto due approcci per la realizzazione di Web Service. Quello che abbiamo approfondito in questa sede è l'approccio basato sui principi REST, mentre fino a qualche anno fa l'approccio principale era quello basato sul protocollo SOAP. Questo tipo di Web Service, a cui HTML.it ha dedicato una guida specifica, è noto anche come WS-*, con un chiaro richiamo al prefisso utilizzato nei vari standard definiti dal W3C.
Anche se l'obiettivo dei due approcci è pressoché identico, cioè l'adozione del Web come piattaforma di elaborazione, la loro visione e la soluzione suggerita sono totalmente differenti.
Risulta utile fare un confronto tra i due approcci per comprendere queste differenze.
Risorse e servizi a confronto: la differenza tra REST e SOAP
La prima evidente differenza tra i due tipi di Web Service è la visione del Web proposta come piattaforma di elaborazione. REST propone una visione del Web incentrata sul concetto di risorsa mentre i SOAP Web Service mettono in risalto il concetto di servizio.
- Un Web Service RESTful è custode di un insieme di risorse sulle quali un client può chiedere le operazioni canoniche del protocollo HTTP
- Un Web Service basato su SOAP espone un insieme di metodi richiamabili da remoto da parte di un client
L'approccio dei SOAP Web service ha mutuato un'architettura applicativa denominata SOA, Service Oriented Architecture, a cui si è recentemente contrapposta l'architettura ROA, Resource Oriented Architecture, ispirata ai principi REST.
Il protocollo SOAP (Simple Object Access Protocol) definisce una struttura dati per lo scambio di messaggi tra applicazioni, riproponendo in un certo senso parte di quello che il protocollo HTTP faceva già. SOAP utilizza HTTP come protocollo di trasporto, ma non è limitato nè vincolato ad esso, dal momento che può benissimo usare altri protocolli di trasporto.
A differenza di HTTP, però, le specifiche di SOAP non affrontano argomenti come la sicurezza o l'indirizzamento, per i quali sono stati definiti standard a parte, nello specifico WS-Security e WS-Addressing.
Quindi SOAP non sfrutta appieno il protocollo HTTP, utilizzandolo come semplice protocollo di trasporto. REST invece sfrutta HTTP per quello che è, un protocollo di livello applicativo, e ne utilizza appieno le potenzialità.
Vantaggi e svantaggi di Web Service basati su SOAP e REST
È evidente che l'approccio adottato dai Web Service basati su SOAP è derivato dalle tecnologie di interoperabilità esistenti al di fuori del Web e basato essenzialmente su chiamate di procedura remota, come DCOM, CORBA e RMI. In sostanza questo approccio può essere visto come una sorta di adattamento di queste tecnologie al Web.
L'approccio REST, invece, tende a conservare e ad esaltare le caratteristiche intrinseche del Web evidenziandone la predisposizione ad essere una piattaforma per l'elaborazione distribuita. Quindi, non è necessario aggiungere nulla a quanto è già esistente sul Web per consentire ad applicazioni remote di interagire.
Inoltre i Web Service basati su SOAP prevedono lo standard WSDL, Web Service Description Language, per definire l'interfaccia di un servizio. Questa è un'ulteriore evidenza del tentativo di adattare al Web l'approccio di interoperabilità basato su chiamate remote. Infatti il WSDL non è altro che un IDL (Interface Description Language) per un componente software.
Da un lato l'esistenza di WSDL favorisce l'uso di tool per creare automaticamente client in un determinato linguaggio di programmazione, ma allo stesso tempo induce a creare una forte dipendenza tra client e server.
Eccezioni previste dal Web Service di tipo REST
REST non prevede esplicitamente nessuna modalità per descrivere come interagire con una risorsa. Le operazioni sono implicite nel protocollo HTTP. Qualcosa di analogo a WSDL è WADL, Web Application Definition Language, un'applicazione XML per definire risorse, operazioni ed eccezioni previsti da un Web Service di tipo REST.
WADL è stato sottoposto al W3C per la standardizzazione nel 2009, ma allo stato attuale non ci sono piani per la sua discussione ed eventuale approvazione. In realtà esso non ha avuto una accoglienza molto favorevole da parte della comunità REST, in quanto offre una visione statica di un Web Service, contraddicendo il principio HATEOAS che pone nella presenza di collegamenti all'interno della rappresentazione di una risorsa la definizione di un contratto con il client, con una visione quindi molto
più dinamica e un debole accoppiamento tra client e server.
In conclusione, i Web service basati su SOAP costruiscono un'infrastruttura prolissa e complessa al di sopra del Web per fare cose che il Web è già in grado di fare. Il vantaggio di questo tipo di servizi è che in realtà definisce uno standard indipendente dal Web e l'infrastruttura può essere basata anche su protocolli diversi.
REST invece intende ripristinare il Web ad architettura per la programmazione distribuita, senza aggiungere sovrastrutture non necessarie.
