Sai cos’è un Web Service? Eppure lo usi Tutti i Giorni!

Un Web Service è la disponibilità di un servizio attraverso il Web. Un esempio pratico di Web Service sono le prenotazioni online come un volo o una camera d’albergo. Puoi compiere questa operazione perché il tuo computer interroga un server che colleziona tutte le diverse disponibilità (in base ai tuoi criteri di ricerca) e ti permette di scegliere.

Mettiamo che tu debba viaggiare da X a Y in data Z. Il Server interroga le diverse linee aeree che compiono la tua tratta e ti restituisce online i risultati possibili. Attenzione a non confonderti: non si tratta di una interrogazione al data base, non sarebbe possibile per motivi di sicurezza. Le disponibilità di un posto  ti vengono restituite grazie ad un collegamento in tempo reale (collegamento real time), dato che le linee aree espongono i loro dati attraverso una API che il Server interroga con la tecnica del Web Service.

In poche parole il Web Service è una piattaforma indipendente di comunicazione che permette, attraverso uno standard (di comunicazione), a diverse applicazioni di dialogare tra loro.

Come funziona un Web Service, guida pratica

Abbiamo detto che il Web Service consente a diverse applicazioni di scambiarsi dati tra loro, dialogando attraverso uno standard di comunicazione. Questa è una definizione piuttosto esaustiva di cosa sia un Web Service. Ma come avviene questo scambio di dati, nello specifico?

Un PC (chiamiamolo anche Client o Service Consumer)  manda una richiesta a un Service Provider che risponde. Ad esempio, il tuo computer richiede un volo da X a Y in data Z. Affinché la comunicazione tra Client e Service Provider avvenga, è necessario avere

• Un Medium, ovvero uno strumento della comunicazione (come il protocollo http/internet)

• Un Formato, ovvero una lingua compresa dalle diverse applicazioni (come json/Xml)

Esistono due tipi di Web Service che si servono di differenti Medium e Formati: si chiamano SOAP (Simple Object Access Protocol) e REST (Representational State Transfer). Vediamo i loro dettagli:

• Web Service SOAP (Medium http (POST) e Formato Xml)

• Web Service REST (Medium http (POST, GET, PUT DELETE) e Formato Xml, Json, Text)

Cosa sono i WSDL? Interfacce che descrivono le diverse funzionalità dei Web Service

Adesso che conosci (o hai rinfrescato, se lo conoscevi già) il concetto di Web Service, dei Medium e dei Formati per la comunicazione, introduciamo il concetto di WSDL. Questa sigla in inglese sta ad indicare un  Web Services Description Language, ovvero l’interfaccia Xml che descrive le funzionalità dei Web Service. Online, esistono diversi esempi di WDSL. Come si vede in questo esempio di sito Global Weather, WSDL è scritto nel linguaggio Xml e contiene i parametri e la tipologia del servizio fornito.

Come ultima cosa non ci resta che introdurre la sigla UDDI che sta per Universal Description Discovery and Integration. Si tratta di una directory (una cartella) dove il Service Consumer (che abbiamo anche chiamato Client) effettua la sua query (interrogazione), ottenendo i dati Web Service. Ogni Service provider, dunque, pubblica il proprio Web Service in una directory usando il WSDL. All’interno di questa cartella il Service consumer effettua la sua ricerca. Possiamo quindi affermare che UDDI è un Xml standard per pubblicare e trovare Web Services.

L’universo dei SOAP e dei RESTFUL Web Service, i dettagli tecnici

Torniamo adesso alle nostre sigle SOAP e RESTFUL che altro non sono se non i due tipi di Web Service che abbiamo individuato prima. In questo paragrafo del nostro articolo troverai i dettagli tecnici.

1. SOAP, ovvero Simple Object Access Protocol. Questo protocollo stabilisce una serie di regole grazie alle quali Server consumer e Service provider possono dialogare tra loro. La comunicazione avviene attraverso il formato Xml. Ecco la struttura che i messaggi Xml devono avere per SOAP: avremo un Envelope (ovvero contenitore per Header e Body); un Header (che è opzionale e contiene informazioni come routing e autenticazione) e per finire un Body (che altro non è se non il contenuto del messaggio). Sempre nel tuo caso dell’aereo, il body sono i dati che il Service consumer (o Client) ha chiesto al Server.

2. RESTFUL, ovvero Representational State Transfer. Questo secondo tipo di Web Service (come vedremo dai dettagli tecnici) è molto più popolare di SOAP, per la sua semplicità. In SOAP infatti, per reperire una risorsa devi usare un envelope Xml, mentre in REST basterà un link (metodo GET).

Affinché un Web Service sia RESTful, devono essere soddisfatti i seguenti principi:

• Uniform Interface: le Resources, possono essere identificate da URI, attraverso http

• Sateless: ogni richiesta tra consumer e provider è indipendente e il server non ricorda nessuna informazione di una comunicazione precedente.

• Cacheable: ogni dato inviato dal Server a seguito di una richiesta, contiene una informazione che identifica se deve essere ricordato dal Client. La risposta del server contiene un header con cache Control e last value.

• Layers: livelli multipli possono esistere tra Client e Server

• Code on Demand: possibilità di eseguire codice lato Client

La REST Uniform Interface (Resources, URI, http) si basa sui concetti di Resources, URI e http. Vediamo più nel dettaglio:

• Resources: si tratta dei moduli/dati che sono oggetto della comunicazione tra le due applicazioni. Le due applicazioni sono da un lato il Service provider, ovvero il fornitore del servizio e dall’altro il Service consumer detto anche Client. Se facessimo l’esempio di  un data base aziendale, Resources sono i dati relativi agli impiegati con la loro anagrafica. Oppure sono le diverse Direzioni, con gli uffici collegati. Oppure ancora sono le Filiali aziendali con le rispettive sedi geografiche e i settori organizzativi. Insomma, in REST ogni informazione può essere una risorsa e viene  identificata da un nome.

• URI: Attraverso il Uniform Access Identifier, detto appunto URI, si può accedere ad ogni dato o risorsa. Tornando all’esempio dell’azienda e ammesso che questa azienda abbia un proprio sito internet in cui archivia le proprie risorse (dati) organizzative, avremo tutte le Risorse ospitate nel dominio nomedominio.com e in particolare:

1. Elenco degli impiegati: nomedominio.com/impiegati

2. Informazioni di un impiegato{nome}: nomedominio.com/impiegati/{nome}

3. Elenco delle Direzioni: nomedominio.com/direzioni

4. Informazioni Direzione Personale: nomedominio.com/direzioni/Personale

5. Impiegati Direzione Personale : nomedominio.com/Personale/Impiegati

• HTTP: ha dei metodi GET, POST, PUT; DELETE. Con questi può essere creata una funzione chiamata CRUD. CRUD è un acronimo che sta per il seguente processo

C=CREATE=POST

R=READ= GET

U=UPDATE=PUT

D= DELETE= DELETE

Usando il metodo GET , descritto di seguito, la lista degli impiegati della nostra azienda-esempio, verrà fornita digitando la seguente URL:  http//: GET www.nomedominio.com/impiegati

A questo punto, nel RESTful Web Service, ogni risorsa può essere identificata attraverso un Nome, un URI e un http e manipolata attraverso la sua rappresentazione (Xml, Json ecc…). La sintesi appena fatta è in questo paragrafo è importante per  identificare le differenze tra SOAP e RESTful. In pochissime parole, la differenza sta che in SOAP per reperire una risorsa devo usare un envelope Xml, in REST basterà un link (grazie al metodo GET). Ecco perché REST è molto piu’ popolare di SOAP, per la sua semplicità.

Questo articolo è un Guest Post di Walter Livio Bollini. Laureato in Matematica/informatica, con un  Master in tecnologia digitale, è specializzato in linguaggio PHP. È esperto del Web e della realizzazione di applicazioni tra cui l’e-commerce. Realizza anche campagne di Web Marketing, newsletter, gestione social network. Sito personale: https://www.liviobollini.it