L’argomento stavolta è REST (REpresentational State Transfer), vera e propria filosofia informatica. Infatti, la prima volta di cui se ne parlò fu nel 2000, nel capitolo 5 della tesi di PhD in Filosofia Informatica di Roy Fielding, uno dei principali autori delle specifiche HTTP, dal titolo Architectural Styles and the Design of Network-based Software Architectures.
Ma cosa è veramente REST? Uno standard, un modello o cosa? Purtroppo non è ancora un vero e proprio standard e, forse, non è neanche giusto che lo sia. Definisce un modello di progettazione di architetture software o, elegantemente, uno “stile architetturale”. L’idea di base del REST è quella di vedere il Web (ma anche altri “sistemi”) come una piattaforma per l’elaborazione distribuita dei dati. E il Web ha già tutto quello di cui si ha bisogno, ossia l’infrastruttura che si basa sul protocollo HTTP e le informazioni, che diventano vere e proprie risorse. Non ha senso inserire un overhead ulteriore e, dunque, uno strato software come avviene con i Web Services in SOAP.
Riporto un passo estratto dalla tesi di Fielding in cui si introduce il senso di questo stile:
The Representational State Transfer (REST) style is an abstraction of the architectural elements within a distributed hypermedia system. REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements. It encompasses the fundamental constraints upon components, connectors, and data that define the basis of the Web architecture, and thus the essence of its behavior as a network-based application. […]
REST emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems. I describe the software engineering principles guiding REST and the interaction constraints chosen to retain those principles, contrasting them to the constraints of other architectural styles.
Questo stile è diventato molto in voga negli ultimi anni per la realizzazione di Web Services altamente scalabili ed efficienti. Per approfondire l’argomento e per esempi pratici, ecco il link alle lezioni di HTML.it: RESTful Web Services – La guida, da cui ho estratto gran parte delle informazioni qui di seguito riportate.
Ecco i 5 principi su cui si basa il REST:
- identificazione delle risorse
- utilizzo esplicito dei metodi HTTP
- risorse autodescrittive
- collegamenti tra risorse
- comunicazione senza stato
- preferire l’utilizzo di nomi a quello di verbi
- contenere la lunghezza degli URI
- preferire uno schema posizionale, ossia una struttura gerarchica di un percorso piuttosto che la presenza di più argomenti: http://www.mionegozio.com/ordini/2011/07/01 al posto di http://www.mionegozio.com/ordini/?anno=2001&mese=07&giorno=0
- evitare le estensioni, che legano un Web Service alla sua implementazione: ad esempio, è da preferire un URI del tipo:
http://www.mionegozio.com/ordini/ordine.php?id=123
- POST –> Create (Crea un nuova risorsa)
- GET –> Read (Ottiene una risorsa esistente)
- PUT –> Update (Aggiorna una risorsa o ne modifica lo stato)
- DELETE –> Delete (Elimina una risorsa)
- Lo stato delle risorse è dato dall’insieme dei valori delle caratteristiche di una risorsa in un dato momento. Un Web Service è responsabile della gestione dello stato delle risorse. Un client può accedere allo stato di una risorsa tramite le diverse rappresentazioni della risorsa stessa e contribuire a modificarlo per mezzo dei metodi PUT, POST e DELETE dell’HTTP.
- Lo stato del client è rappresentato dall’insieme del contesto e delle risorse ottenute in uno specifico momento. Il server può influenzare le transizioni di stato del client inviando differenti rappresentazioni in risposta alle sue richieste.
- Lo stato dell’applicazione, cioè del risultato dell’interazione tra client e server, è dato dallo stato del client e delle risorse gestite dal server. Lo stato dell’applicazione determina le modalità di modifica dello stato delle risorse e del client.
A differenza di quanto avviene in buona parte delle applicazioni Web, dove lo stato dell’applicazione viene spesso mantenuto dal server insieme allo stato della comunicazione, lo stato dell’applicazione in un’architettura RESTful è il frutto della collaborazione di client e server, ciascuno con i propri ruoli e responsabilità.
Come da acronimo, una applicazione passa da uno stato all’altro, principio noto come HATEOAS, usando i collegamenti ipertestuali: una applicazione è intesa come rete di risorse in cui un client naviga seguendo i collegamenti ammissibili tra una risorsa e l’altra, come una macchina a stati finiti.
Un bel articolo sulle differenze tra SOAP e RESTful, lo potete leggere sempre su HTML.it:
RESTful VS. SOAP. REST propone una visione del Web incentrata sul concetto di risorsa mentre i SOAP Web Service mettono in risalto il concetto di servizio.
- Un Web Service RESTful è custode di un insieme di risorse sulle quali un client può chiedere le operazioni canoniche del protocollo HTTP
- Un Web Service basato su SOAP espone un insieme di metodi richiamabili da remoto da parte di un client
L’approccio dei SOAP Web service ha mutuato un’architettura applicativa denominata SOA, Service Oriented Architecture, a cui si è recentemente contrapposta l’architettura ROA, Resource Oriented Architecture, ispirata ai principi REST. SOAP utilizza HTTP come protocollo di trasporto, ma non è limitato né vincolato ad esso, dal momento che può benissimo usare altri protocolli di trasporto. SOAP non sfrutta a pieno il protocollo HTTP, utilizzandolo come semplice protocollo di trasporto. REST invece sfrutta HTTP per quello che è, un protocollo di livello applicativo, e ne utilizza a pieno le potenzialità.
È evidente che l’approccio adottato dai Web Service basati su SOAP è derivato dalle tecnologie di interoperabilità esistenti al di fuori del Web e basato essenzialmente su chiamate di procedura remota, come DCOM, CORBA e RMI. In sostanza questo approccio può essere visto come una sorta di adattamento di queste tecnologie al Web.
Inoltre i Web Service basati su SOAP prevedono lo standard WSDL, Web Service Description Language, per definire l’interfaccia di un servizio. Questa è un’ulteriore evidenza del tentativo di adattare al Web l’approccio di interoperabilità basato su chiamate remote. Infatti il WSDL non è altro che un IDL (Interface Description Language) per un componente software. Da un lato l’esistenza di WSDL favorisce l’uso di tool per creare automaticamente client in un determinato linguaggio di programmazione, ma allo stesso tempo induce a creare una forte dipendenza tra client e server.
REST non prevede esplicitamente nessuna modalità per descrivere come interagire con una risorsa. Le operazioni sono implicite nel protocollo HTTP. L’approccio REST tende a conservare e ad esaltare le caratteristiche intrinseche del Web evidenziandone la predisposizione ad essere una piattaforma per l’elaborazione distribuita. Quindi, non è necessario aggiungere nulla a quanto è già esistente sul Web per consentire ad applicazioni remote di interagire.

This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2012/10/07/rest-lo-stile-architetturale-restful-il-web-ha-gia-tutto-quello-di-cui-si-ha-bisogno/.
Pingback: [Javascript] Un nuovo modo di scrivere il front-end con Backbone.js + CoffeeScript
Ciao Francesco,
leggo sempre con piacere articoli ben fatti.
Bye,
Antonio.
Complimenti anche per il tuo blog Antonio. Grazie!
una guida introduttiva ai servizi Restfull molto esplicativa. Ottima per una idea iniziale sui servizi, forse andrebbe aggiornare con qualche esempio.
grazie
* aggiornata
Grazie Mauro. Appena troverò un pò di tempo lo farò. Intanto ti consiglio di leggere la specifica JSON-RPC 2.0, che sto trovando molto interessante: http://www.jsonrpc.org/specification