Volendo essere formali, REST definisce un insieme di principi architetturali per la progettazione di un sistema. Rappresenta uno stile architetturale, cioè non si riferisce ad un sistema concreto e ben definito né si tratta di uno standard stabilito da un organismo di standardizzazione.
La sua definizione è apparsa per la prima volta nel 2000 nella tesi di Roy Fielding, Architectural Styles and the Design of Network-based Software Architectures, discussa presso l'Università della California, ad Irvine. In questa tesi si analizzavano alcuni principi alla base di diverse architetture software, tra cui appunto i principi di un'architettura software che consentisse di vedere il Web come una piattaforma per l'elaborazione distribuita.
È bene precisare che i principi REST non sono necessariamente legati al Web, nel senso che si tratta di principi astratti di cui il World Wide Web ne risulta essere un esempio concreto.
All'epoca questa visione del Web passò un po' in sordina, ma negli ultimi anni l'approccio REST è venuto alla ribalta come metodo per la realizzazione di Web Service altamente efficienti e scalabili ed ha al suo attivo un significativo numero di applicazioni.
Il motivo è semplice: dal momento che il Web ha tutto quello che serve per essere considerata una piattaforma di elaborazione distribuita secondo i principi REST, non sono necessarie altre sovrastrutture per realizzare quello che è il Web programmabile. Il che è una dichiarazione di aperto antagonismo ai Web Service basati su SOAP.
Che cos'è REST?
Abbiamo detto che REST non è un'architettura né uno standard, ma un insieme di linee guida per la realizzazione di una "architettura di sistema". Ma quali sono questi principi che rendono il Web adatto a realizzare Web Service secondo l'approccio REST?
Il tutto può essere riassunto nei seguenti cinque principi:
- Identificazione delle risorse
- Utilizzo esplicito dei metodi HTTP
- Risorse autodescrittive
- Collegamenti tra risorse
- Comunicazione senza stato
Questi principi rappresentano in realtà concetti ben noti perché ormai insiti nel Web che conosciamo. Li analizzeremo tuttavia sotto una prospettiva diversa, quella della realizzazione di Web Service.
Identificazione delle risorse
Le risorse sono gli elementi fondamentali su cui si basano i Web Service RESTful, a differenza dei Web Service SOAP-oriented che sono basati sul concetto di chiamata remota.
Per risorsa si intende un qualsiasi elemento oggetto di elaborazione. Per fare qualche esempio concreto, una risorsa può essere un cliente, un libro, un articolo, un qualsiasi oggetto su cui
è possibile effettuare operazioni. Per fare un parallelo con la programmazione ad oggetti possiamo dire che una risorsa può essere assimilata ad una istanza di una classe.
Il principio che stiamo analizzando stabilisce che ciascuna risorsa deve essere identificata univocamente. Essendo in ambito Web, il meccanismo più naturale per individuare una risorsa è dato dal concetto di URI.
Il principale beneficio nell'adottare lo schema URI per identificare le risorse consiste nel fatto che esiste già, è ben definito e collaudato e non occorre pertanto inventarsene uno nuovo.
I seguenti sono esempi di possibili identificatori di risorse:
http://www.myapp.com/clienti/1234http://www.myapp.com/ordini/2011/98765http://www.myapp.com/prodotti/7654http://www.myapp.com/ordini/2011http://www.myapp.com/prodotti?colore=rosso
Gli URI sono abbastanza autoesplicativi: i primi tre identificano rispettivamente un determinato cliente, un ordine ed un prodotto. Il quarto URI identifica l'insieme degli ordini del 2011, mentre l'ultimo URI identifica l'insieme dei prodotti di colore rosso.
L'interpretazione che abbiamo dato a questi URI è però desunta dalla semantica delle parole contenute nelle sue parti. Dal punto di vista di un Web Service un URI è soltanto una stringa che identifica una risorsa, per cui anche http://www.myapp.com/tgw34/2099ww può essere un URI valido per identificare un cliente.