Ragionando sui Web Services 2.0

Parlando di web services sembra scontato il riferimento a standard tecnologici come SOAP, UDDI, ecc. Queste tecnologie costituiscono infatti al momento lo stato dell’arte nell’offerta standardizzata di servizi su web (e non solo); esistono piattaforme commerciali e open che consentono di realizzare web services con queste tecnologie sfruttando i più diffusi linguaggi del momento; così come ne esistono per semplificare il loro utilizzo lato client.

Ciononostante, appresntandomi a disegnare un nuovo Web Service in stile 2.0 (vedi anche Ragionando sulle Web App 2.0), ho provato ad esaminare le soluzioni scelte da alcune delle realtà che stanno riscuotendo maggiore attenzione. Non è sempre detto che dietro ad un’idea di servizio vincente ci sia necessariamente un buon design, ma in questo caso ho trovato quanto meno istruttivo questo esame comparato.

Il caso Amazon

I primi dubbi sono nati dall’analisi fatta sul caso Amazon. Amazon offre diversi servizi con una duplice interfaccia: SOAP e REST. Quest’ultimo è in realtà un protocollo incentrato più sul concetto di risorsa che su quello di servizio: in effetti il servizio offerto è quello di manipolazione delle risorse secondo quattro azioni standard (PUT, GET, POST, DELETE) assimilabili, in prima approssimazione, alle classiche CRUD. Bene, pare che l’85% degli utenti di questi servizi abbia scelto l’interfaccia di tipo REST. Il motivo fondamentale, che può essere percepito da chiunque si cimenti nello sviluppo di applicazioni che richiamino tali servizi, è nella semplicità di interazione che un interfaccia REST (o simil REST) offre.

La semplicità nell’utilizzo di un servizio può essere un elemento importante nella diffusione del servizio stesso, specie se questo è rivolto non tanto o non solo a team di ingegneri del software ma anche a volenterosi artisti del cut&paste che con poche righe di codice “rubate” qua e là riescono a integrare applicazioni vincenti. Per la cronaca Amazon offre i suoi servizi, fra l’altro, affinché vengano costruiti canali di vendita alternativi al sito Amazon che siano meno generalisti e riescano ad intercettare la domanda che a loro sfugge (naturalmente con profitto per tutte le parti).

Il caso Flickr

Flickr è probabilmente una delle icone del Web 2.0. Non è il primo sito ad offrire la possibilità di pubblicare le proprie foto in rete, ma è forse il primo a concepire la condivisione di foto (e non solo) come un servizio. Flickr offre tre protocolli di interfaccia distinti per richiamare i propri servizi: SOAP, REST e XML-RPC; quest’ultimo è forse una delle prime modalità di realizzazione di un web service e si basa sulla codifica in XML di una chiamata a procedura remota. Inoltre Flickr può vantare un ampio campionario di API realizzate da terze parti per diversi ambienti di programmazione che si basano sempre sulle tre modalità di interfaccia proposte.

L’aspetto interessante è che qualunque sia il protocollo utilizzato per invocare il servizio, il risultato (una volta estratto dall’involucro SOAP o XML-RPC) è sempre una stringa di testo, e nella fattispecie testo XML. Ossia tutte le funzioni restituiscono porzioni di XML che rappresentano il risultato dell’invocazione del servizio indipendentemente dalle modalità di rappresentazione dei tipi di dato complessi previste da SOAP o XML-RPC. Anche SOAP o XML-RPC utilizzano XML per codificare i dati, oltretutto in maniera standardizzata in modo che “lato client” si possa accedere direttamente alle strutture dati restituite delegando il parsing dell’XML al middleware standard. Eppure l’utilità e la semplicità della scelta di Flickr risiede nel fatto che molte Web App si limitano ad invocare i servizi e a formattarne il risultato con CSS o XSLT, pertanto la rappresentazion del risultato in un XML lineare e strettamente calato sul dominio di business risulta essere la soluzione più pratica. Tale filosofia è ancora una volta quella intrinsecamente promossa dall’approccio REST (nella sua accezione più blanda di XML+HTTP).

Altri casi

Giusto per citare qualche altro caso diciamo che del.icio.us implementa unicamente un interfaccia di tipo REST (ancora in fase di sviluppo) mentre eBay, uno degli esempi più maturi, offre (similmente ad Amazon) sia SOAP che REST; Google offre unicamente un interfaccia SOAP canonica mentre molti motori di Blog (di diritto nel campionario del Web 2.0) utilizzano XML-RPC per la gestione dei trackback.

Tabella riassuntiva

Considerazioni finali

Questo post non vuole essere un invito ad abbandonare l’approccio formale e strutturato di SOAP, WSDL, BPEL, ecc. e il supporto degli ambienti per la costruzione e l’erogazione di web services che su tali standard si basano. Queste tecnologie sono probabilmente al momento le più idonee per la realizzazione di soluzioni “istituzionali” di tipo SOA. Tuttavia, nella realizzazione di servizi innovativi (2.0), rivolti direttamente ad un pubblico (di smanettoni) più ampio e il cui successo è legato anche ai contributi della community, altre soluzioni quali REST meritano di essere prese in considerazione, specie visti i casi di successo citati.

Anche il modello REST propone un approccio formalizzato all’organizzazione del servizio, ma come spesso succede in assenza di implementazioni di riferimento, ci sono diversi modi (più o meno fedeli) di applicarlo e anche i casi citati non sembrano aver interpretato a pieno l’impianto metodologico proposto da Roy Fielding.

3 Replies to “Ragionando sui Web Services 2.0”

  1. Credo che questa presentazione sulla riconciliazione fra RESTful e SOAP-based web services, oltre ad interessanti spunti di riflessione sulla possibilità di combinare i due approcci, offra un’ulteriore testimonianza della rilevanza del fenomeno REST. Ho trovato interessante anche il confronto fra pregi e limiti di entrambi gli approcci.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *