Introduzione

Volendo seguire la filosofia secondo la quale è inutile reinventare la ruota, siamo velocemente approdati ad una discussione su due metodologie di interazione tra moduli software, basate entrambe su http: XML-RPC e ReST. In questo documento si vogliono presentare le principali differenze tra queste due filosofie, e le motivazioni che porteranno alla scelta di una a favore dell'altra. Inoltre sarà presentata una breve panoramica degli strumenti disponibili per i linguaggi adottati.

Cosa hanno in comune XML-RPC e ReST

Entrambe le filosofie di interazione si basano su http: il servizio viene reso disponibile attraverso un application server web, e il client ne usufruisce attraverso chiamate http.

Cosa hanno di diverso XML-RCP e ReST

Il tipo di protocollo di comunicazione in XML-RCP dipende dalla sue implementazione. Sia server e client devono utilizzare librerie specifiche di tale implementazione (ad esempio SOAP, forse la più conosciuta), e utilizzare la loro sintassi per chiamare metodi di oggetti sul server, e ottenere risposte. Le richieste, così come le risposte ottenute, sono incapsulate quindi in un protocollo specifico.

La filosofia ReST affronta il problema in maniera differente, esprimendo le chiamate come GET http (più raramente POST), indirizzando in questo modo oggetti, chiamandone i metodi, passandone i parametri.

Perché preferire ReST

Perché fare una cosa complicata, quando si può farne una più semplice? Utilizzando l'approccio ReST le chiamate ad un servizio avrebbero una forma di questo tipo:

>>> http://hostname:port/path/object/method?par1=val1&par2=val2

Le chiamate sono facilmente interpretabili, magari testabili anche con un browser web, che ben si adatta come client.

Perché preferire XML-RCP

Perché SOAP (la più diffusa implementazione XML-RPC) è citato e raccomandato in parecchia documentazione del codice digitale della Pubblica Amministrazione.

E noi cosa facciamo?

La discussione è aperta, ma per non rimanere con le mani in mano, proveremo ad implementare un piccolo webservice scaturito da un esigenze puntuale del ced del Comune di Riva: la necessità di richiamare da remoto una procedura per la creazione di un hash sha su dei file presenti sul filesystem remoto. L'approccio iniziale sarà ReST, mentre in seguito verrà valutata la complessità di introdurre un wrapper verso SOAP. Ecco il link all'esempiosha_.