Un servizio web `e un componente software accessibile tramite la rete. Il punto di forza dei servizi web `e che essi sono indipendenti dalle tecnologie im- piegate. Vengono infatti definite delle interfacce per accedere a delle funziona- lit`a che sono indipendenti dall’hardware, dal sistema operativo e dal linguaggio di programmazione utilizzato. E’ per esempio possibile fornire un servizio web in Node.JS e accedervi tramite un client Android, Java, IOS e/o altro. In que- sta maniera inoltre i client costruiti con tecnologie diverse possono comunicare tra di loro grazie a servizi web. Esistono diversi modi per costruire servizi web, tra cui l’approccio REST (REpresentational State Transfer), in cui le risorse sono i servizi web. Grazie al fatto che in questo approccio si utilizzano protocolli internet (HTTP) e formati di messaggi standard (JSON, XML..) `e possibile quindi sviluppare client e server con diverse tecnologie. Negli ultimi anni la crescita della diffusione di questo approccio `e stata enorme, e difatti
attualmente questo approccio `e lo standard de facto per le imprese che forni- scono i loro servizi con un modello di consumazione di risorse web. E’ stato infatti adottato dalle maggiori compagnie al mondo, tra le quali Google, Face- book, Yahoo.. REST si pu`o descrivere come una architettura in cui convivono componenti disaccoppiati tra loro che comunicano tramite interfacce costruite sui protocolli web standard. Di seguito vengono illustrati i quattro principi portanti di REST:
• Identificazione delle risorse tramite URI : le risorse sono identificate da degli URI. Esse inoltre sono organizzate come se fossero delle directory (quindi ad albero). Questo facilita anche la comprensione dei concetti da parte degli sviluppatori e non solo. Ad esempio:
http://www.myservice.org/forum/threads/{thread_id}
Supponiamo che ci sia un forum online. La radice sar`a appunto il forum, in cui sono presenti svariati thread. Il thread che ci interessa `e identificato da un id
• Manipolazione delle risorse tramite un set di operazioni (metodi HTTP): le risorse possono venire manipolate tramite delle richieste HTTP. Una richiesta si compone di queste parti:
– VERB: nome del metodo HTTP – URI: URI della risorsa
– HTTP Version: versione di HTTP da usare
– Request Header: collezione di metadati in formato chiave valore che riguardano la tipologia del messaggio e caratteristiche di esso – Request body: contenuto del messaggio, quindi la rappresentazione
di una risorsa
La risposta invece `e simile alla richiesta, ma differisce per il fatto che non `e presente VERB e URI ma `e invece presente il Response Code (tipicamente i codici a tre cifre degli stati HTTP, per indicare appunto lo stato della richiesta, ovvero se `e stata completata con successo o se ci sono stati dei problemi, e in caso quali). Di seguito vengono illustrate le richieste HTTP di base che permettono la manipolazione delle risorse:
– PUT (update): cambiamento di stato di una risorsa esistente. Esem- pio di PUT:
PUT /users/Robert HTTP/1.1 Host: myserver Content-Type: application/xml <?xml version="1.0"?> <user> <name>Bob</name> </user>
Si noti la composizione della richiesta rispetto a quanto detto prima: ∗ VERB: in questo caso `e ”PUT”
∗ URI: in questo caso `e ”/users/Robert”) ∗ HTTP Version: in questo caso `e ”HTTP/1.1”
∗ Request Header: in questo caso `e ”Content-Type: applicatio- n/xml”)
∗ Request body: in questo caso `e il codice XML
– DELETE (delete): eliminazione di una risorsa. Esempio di DELE- TE:
DELETE /users/Robert HTTP/1.1 Host: myserver
Accept: application/xml
– GET (read): recupero della rappresentazione di una risorsa. Si effettua una GET ad un URI specifico per recuperare direttamente una risorsa, oppure fornire dei parametri grazie ai quali il server possa restituire una determinata risorsa cercata. Esempio di GET:
GET /users/Robert HTTP/1.1 Host: myserver
Accept: application/xml
– POST (create): creazione di una nuova risorsa. Esempio di POST:
POST /users HTTP/1.1 Host: myserver Content-Type: application/xml <?xml version="1.0"?> <user> <name>Robert</name> </user>
Nessuno obbliga a seguire questo modello, nel senso che `e possibile ad esempio effettuare l’aggiornamento di una risorsa tramite GET. Tutta- via questo approccio, oltre ad essere un’inconsistenza a livello semantico (dato che la GET `e stata progettata per recuperare risorse e non per altro), porta anche a problemi pratici, in quanto i crawler o i motori di ricerca potrebbero involontariamente far partire delle modifiche alle risorse semplicemente navigando dei link. Per evitare side effect `e quindi consigliato di seguire le linee guida e di utilizzare i metodi HTTP per quello per cui sono stati pensati
• Rappresentazione delle risorse: le risorse sono disaccoppiate dalla loro rappresentazione, in questo modo `e possibile rappresentarle in diverse forme (XML, JSON, HTML, PDF etc). La rappresentazione di una risorsa quindi incapsula le informazioni relative ad essa al momento in cui avviene la richiesta
• Interazioni senza stato: le interazioni con le risorse sono senza stato. Lo stato viene trasferito esplicitamente nei messaggi. La mancanza dello stato `e giustificata dalla necessit`a di costruire applicazioni scalabili in modo da avere buone prestazioni. A tal scopo le richieste dei client de- vono contenere tutti i dati che servono affinch`e la richiesta possa venire processata (in modo tale da facilitare anche operazioni di load balan- cing come forwarding di richieste da un server all’altro). Il client diventa l’unico responsabile del mantenimento dello stato. Tutto questo porta anche alla semplificazione delle applicazioni lato server, in quanto dato che nelle richieste sono contenuti tutti i dati che servono, esse non do- vranno conservare e elaborare dati necessari per essere allineati con lo stato dei client
In conclusione, diversi sono i vantaggi che si ottengono dall’utilizzo dell’archi- tettura REST:
• Migliori prestazioni
• L’interazione senza stato migliora la scalabilit`a
• Semplificazione del codice sia lato server sia lato client (in questo caso anche un semplice browser pu`o facilmente effettuare delle richieste) • Facile individuazione delle risorse grazie agli URI
• Facilit`a nell’aggiungere nuovi tipi di rappresentazioni delle risorse senza dover rinunciare al supporto di altri tipi (esempio aggiungere il supporto ad XML oltre che a JSON)
• Standardizzazione delle interfacce e della rappresentazione delle risorse • Possibilit`a di nascondere la complessit`a delle operazioni lato server (da-
tabase multipli, pi`u servizi, pi`u server..) fornendo solamente delle API che ai consumatori risultano molto semplici da capire e da utilizzare
A.2.1
Mobile computing
Un campo che trae vantaggio dai servizi web (REST in particolare) `e si- curamente il mobile computing. Come noto, i dispositivi mobili sono ormai diventati pervasivi e sono posseduti da quasi tutti. I dispositivi vengono usati da chiunque in qualunque luogo per accedere appunto a servizi in mobilit`a. Nonostante la potenza dei dispositivi mobili stia crescendo di anno in anno, sono ancora presenti limitazioni da questo punto di vista (connessione ad In- ternet non sempre presente e stabile, minori prestazioni, durata della batteria limitata..). Comuni problematiche per i dispositivi mobili e i servizi web sono le seguenti:
• Prestazioni inferiori rispetto ad altre macchine • Problemi di banda e perdita di connessione
• Risorse computazionali limitate (anche se in continua crescita nel tempo) L’introduzione di REST ha migliorato di molto le prestazioni in ambito mobile. Un esempio di test che ha riscontrato le migliori prestaioni di REST rispetto ad altri approcci come SOAP si pu`o trovare qui: [12]. Viene infatti riportato che usare un servizio web REST comporta tempi di risposta drasticamente inferiori rispetto a servizi web SOAP. I motivi sono da ricercare nel fatto che
• I messaggi XML SOAP sono di dimensione maggiore a causa della loro maggiore verbosit`a. Questo fatto pu`o non influire di tanto su sistemi con buone prestazioni, ma si pu`o sentire maggiormente su dispositivi mobili • Possibilit`a di utilizzare meccanismi di caching. Questa possibilit`a con- sente anche di risparmiare molto traffico di rete (e anche di diminuire il carico di lavoro dei server)
Nell’articolo sono descritto dei semplici benchmark che sono stati eseguiti e hanno mostrato le migliori prestazioni di REST.