Web Service

Un web service è prima di tutto un servizio, e quindi possiede le caratteristiche principali di indipendenza dalle tecnologie e loose coupling. Inoltre, ciascun web service è in grado di incapsulare funzionalità discrete, fornisce un'interfaccia ad accesso programmabile, è distribuito su Internet, e può essere composto con altri servizi. In particolare, un servizio web pubblica in rete le proprie capacità computazionali attraverso una o più interfacce programmabili ed è accessibile mediante linguaggi e protocolli Internet standard. Inoltre, ciascun servizio può interagire con altri web service esistenti per delegare loro porzioni della computazione da svolgere.

I Web Service vengono utilizzati per far comunicare diverse applicazioni che lavorano in linguaggi diversi e su piattaforme diverse. Ad esempio, un'applicazione Java che gira su macchina Linux è in grado di comunicare con un altro applicativo scritto in PHP che gira sotto macchina Windows utilizzando i web service. Ci sono attualmente due tipi di web service: SOAP e REST.

Soap/WSDL

Indipendenza dalle tecnologie e loose coupling sono ottenuti utilizzando una serie di standard, tra cui si distinguono il Web Service Description Language (o WSDL), per descrivere in modo universale l'interfaccia offerta dal servizio, e il Simple Object Access Protocol (o SOAP), per la strutturazione dei messaggi contenenti le informazioni scambiate. Poiché basati sullo scambio di messaggi, i web service di tipo SOAP/WSDL vengono definiti message-centric (incentrati sui messaggi).

Il Simple Object Access Protocol, o SOAP, è un protocollo utilizzato per trasferire informazioni da e/o verso web service. In particolare, SOAP si occupa di definire la struttura XML dei messaggi contenenti le informazioni scambiate con un servizio web. Due entità che interagiscono mediante SOAP, quindi, devono trasformare le strutture dati dal linguaggio che utilizzando in documenti XML conformi a SOAP.

SOAP richiede l'utilizzo di un protocollo di trasporto (solitamente HTTP) per raggiungere il destinatario di un messaggio. Ciascun messaggio SOAP viene infatti incapsulato in un pacchetto conforme al protocollo di trasporto selezionato e spedito mediante lo stesso protocollo.

Un messaggio SOAP è un documento XML il cui contenuto è strutturato mediante 3 elementi predefiniti. <soap:Envelope>, <soap:Header> e <soap:Body>

Envelope è l'unico elemento utilizzabile come root element di un messaggio SOAP e deve perciò essere sempre presente.

Un Header SOAP ha lo scopo di contenere l'insieme di informazioni di controllo utili per l'elaborazione del messaggio in cui appaiono, fornendo così una netta separazione tra tali informazioni e il reale contenuto del messaggio, questa netta separazione non è obbligatorio ed il tag è opzionale.

L'elemento Body è obbligatorio e ha il compito di contenere i dati effettivamente spediti dal mittente al destinatario del messaggio.

CRUD

Crud è l'acronico di Create, Read, Update, Delete, che indica l'elenco di azioni che si possono fare ad una risorsa: creazione, lettura, aggiornamento ed eliminazione.

Rest

I servizi di tipo REST, a differenza di quelli SOAP/WSDL, utilizzano un approccio più leggero. Invece di richiedere la definizione di linguaggi ad hoc come WSDL e SOAP, si affidano completamente al protocollo HTTP per lo scambio di informazioni. Sostanzialmente, ciascun servizio è visto come una risorsa su cui effettuare le operazioni tipiche di REST, ovvero DELETE, GET, POST e PUT. Poiché basato sulla virtualizzazione di un servizio come risorsa web, l'approccio dei web service di tipo REST è detto resource-centric (incentrato sulle risorse).

Il REpresentational State Transfer, o REST, è uno stile architetturale per lo sviluppo di applicazioni distribuite scalabili e facilmente estendibili. In particolare, REST costituisce un insieme di principi di architetture di rete che delineano come le risorse di rete sono definite e indirizzate. Tali principi sono elencati di seguito:

un sistema REST deve essere di tipo client-server;
un sistema REST deve essere stateless, ovvero non deve tracciare esplicitamente le sessioni avute con i client, trattando ogni richiesta come indipendente dalle precedenti;
un sistema REST deve avere supportare il caching. Più precisamente, l'infrastruttura di rete deve prevedere meccanismi di cache, possibilmente su più livelli;
un sistema REST deve essere uniformemente accessibile. In particolare, ogni risorsa di rete deve essere accessibile attraverso la stessa interfaccia, e la distinzione tra le varie risorse dipende solamente dal loro identificare univoco;
un sistema REST deve essere layered. Allo scopo di favorire la scalabilità, l'architettura di un sistema REST deve essere organizzata in livelli gerarchici;
un sistema REST può fornire il codice delle applicazioni on demand. Questo vincolo è opzionale, ma quando è implementato consente la manutenzione e l'estensione di applicazioni a tempo di esecuzione.

Tra le varie infrastrutture di rete disponibili, HTTP risulta quella più adatta per implementare sistemi REST (come per SOAP). Il protocollo HTTP, infatti, è pensato per comunicazioni client/server, prevede una gestione indipendente delle richieste e consente lo scambio di qualunque tipo di informazione (eventualmente, anche di codice).

Una risorsa di rete, o risorsa REST, è un qualsiasi oggetto indirizzabile sul web. In particolare, una risorsa REST è un oggetto che può essere acceduto e trasferito tra client e server mediante un predeterminato protocollo di comunicazione. Se il protocollo di comunicazione utilizzato è HTTP, client e server possono scambiarsi un qualunque tipo di risorsa (ad esempio, un articolo di giornale, uno studente di una certa scuola, un indirizzo postale, un video, ecc.), che deve quindi essere propriamente identificata e rappresentata.

Identificazione univoca. La quantità di risorse presenti sulla rete rende necessario assegnare loro un identificatore univoco, per evitare di confondere una risorsa con un'altra. Nei sistemi REST, l'identificazione univoca avviene mediante delle stringhe di caratteri denominate Uniform Resource Identifier, o URI. In particolare, nei sistemi REST che utilizzano HTTP come protocollo di comunicazione, gli URI si identificano con gli Uniform Resource Locator, o URL. In un sistema REST è opportuno non cambiare lo URI assegnato ad una risorsa: se una risorsa cambiasse il proprio identificatore nel tempo, la stessa risorsa potrebbe risultare non più accessibile dagli altri componenti del sistema.

Rappresentazione. Nei sistemi REST, client e server si scambiano la rappresentazione di una risorsa, e non la risorsa reale. In particolare, client e server si scambiano la rappresentazione dello stato di una risorsa così come è al momento della comunicazione. Tale rappresentazione altro non è che un flusso di dati binari, cui sono associati i metadati necessari a descrivere come i dati stessi devono essere consumati.

Accesso alle risorse. Per accedere alle risorse è necessario avere una interfaccia. La soluzione adottata da REST è perciò quella di standardizzare l'interfaccia di accesso alle risorse (risorse di tipo CRUD), prevedendo quattro specifiche operazioni che possono essere effettuate sulle risorse:

POST, per la creazione di una risorsa non ancora esistente in un sistema REST;
GET, per il reperimento dello stato di una risorsa presente in un sistema REST;
PUT, per l'aggiornamento dello stato di una risorsa presente in un sistema REST;
DELETE, per la distruzione di una risorsa presente all'interno di un sistema REST.

Lo stile architetturale REST è particolarmente utile nell'ambito dei servizi web, e consente di sviluppare i cosiddetti RESTful web service. Tali sistemi si caratterizzano combinando i principi architetturali di REST con i principi tipici dei servizi:

un RESTful web service espone l'accesso remoto alla rappresentazione di risorse di vario tipo (ad esempio, dati, procedure, sensori, ecc.);
le operazioni effettuabili su ogni RESTful web service sono quelle presenti nei sistemi HTTP di tipo REST (POST, GET, PUT, e DELETE) e devono essere utilizzate in accordo alla loro semantica;
ciascun RESTful web service è stateless, ovvero non memorizza lo stato delle interazioni con i propri client. Di conseguenza, ogni richiesta inviata da parte di un client deve contenere tutte le informazioni necessarie ad essere servita;
lo stato delle interazioni tra client e server è tipicamente rappresentato e gestito attraverso lo stato delle risorse interessate dalle stesse interazioni.

Rest Vs Soap

Richiesta SOAP

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <getProductDetails xmlns="http://magazzino.example.com/ws">
      <productId>827635</productId>
    </getProductDetails>
  </soap:Body>
</soap:Envelope>

Richiesta REST

http://magazzino.example.com/ws/productDetails/827635

Risposta SOAP

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <getProductDetailsResponse xmlns="http://magazzino.example.com/ws">
      <getProductDetailsResult>
        <productName>Toptimate, set da 3 pezzi</productName>
        <productId>827635</productId>
        <description>Set di valigie; 3 pezzi; poliestere; nero.</description>
        <price>96.50</price>
        <inStock>true</inStock>
      </getProductDetailsResult>
    </getProductDetailsResponse>
  </soap:Body>
</soap:Envelope>

Risposta REST

{ 
    "productName": "Toptimate, set da 3 pezzi", 
    "productId": 827635, "description": "Set di valigie; 3 pezzi; poliestere; nero.", 
    "price": 96.50, 
    "inStock": true
}

API e Web API

Acronimo di Application Programming Interface (in italiano traducibile come Interfaccia di programmazione di un'applicazione), le API sono degli strumenti di programmazione che i linguaggi di programmazioni e le maggiori software house e industrie del mondo informatico – come Microsoft, Google e Facebook – mettono a disposizione degli sviluppatori per facilitare il loro compito nella realizzazione di applicazioni di vario genere. Per esempio tutti i vari metodi presenti delle varie librerie dei linguaggi di programmazione sono API.

Con il termine web API si indica uno specifico URL corrispondente ad un determinato servizio di un Web service che offre una funzione. Spesso per prevenire abusi sull'utilizzo della suddetta Web API le Web API richiedono un "token" o una "key": una stringa di caratteri alfanumerici che identifica lo sviluppatore o il programma.

Per evitare l'uso non autorizzato di API Key si cerca di utilizzare l'HTTPS.

Un esempio pratico sono le API delle Google Maps. La casa di Mountain View mette queste API (così come le application programming interface di moltissimi altri suoi servizi web) a disposizione di tutti gli sviluppatori che le volessero utilizzare per un loro programma o piattaforma web. Sfruttando le API, ad esempio, è possibile utilizzare il servizio di cartografia digitale di Google per realizzare delle mappe personalizzate; oppure integrarle in siti web per servizi di ricerca georeferenziati; o ancora utilizzarle all'interno di applicazioni per smartphone e tablet.

https://maps.googleapis.com/maps/api/geocode/json?address=1600+Amphitheatre+Parkway,+Mountain+View,+CA&key=YOUR_API_KEY

Le API di Facebook, invece, danno la possibilità agli sviluppatori di utilizzare alcune delle funzionalità del social network più famoso al mondo per realizzare delle applicazioni da utilizzare poi nella piattaforma del social network stesso. L'utilizzo di librerie solitamente accessibili esclusivamente al team di sviluppo di Facebook, facilita notevolmente la programmazione di nuove app e funzioni (basta pensare alle decine di giochi presenti nel social network, ad esempio) che arricchiscono l'esperienza degli iscritti di Facebook.

Web-Service