Organizzazione a livelli di REST

Visti i concetti base del protocollo REST passiamo ora alla descrizione più matura del sistema ideato da Richardson e documentato da Martin Fowler. Questo modello consiste

in una visione del protocollo a quattro livelli (figura 3).

Figura 3 Livelli REST

2.4.4 Livello 0

Il livello 0 chiamato The swamp of pox che letteralmente significa “La palude del vaiolo” anche se pox è l'acronimo di “Plain Old Xml”. I sistemi Pox sono quelli che si scambiano messaggi in modo sincrono attraverso il protocollo HTTP.

Secondo Richardson si tratta di una palude in quanto questi servizi cosi strutturati non seguono le direttive REST, e quindi il sistema nel suo complesso risulta non organizzato razionalmente, difficile da controllare, da far evolvere, e così via. Il livello 0 dunque è caratterizzato da sistemi che utilizzano il protocollo di networking alla base del WWW come protocollo di integrazione, limitandosi però a un utilizzo base (request-response sincrono) che non include le direttive REST come identificazione delle risorse, utilizzo di verbi, etc. Pertanto i sistemi a questo livello sono posti alla base, al livello 0, del modello di maturità. L’interazione tra le due componenti è basata su uno scambio sincrono di messaggi XML ( json,csv) attraverso il protocollo HTTPS.

2.4.5 Livello 1

Il livello 1 invece consiste nell'organizzazione dei servizi in termini di risorse. Una risorsa è qualunque cosa accessibile nel web, ossia il cui stato sia trasferibile tra server e client. Il concetto di risorsa è centrale per le architetture REST e una delle direttive base richiede di assegnare a tutte le risorse un identificativo univoco che nel mondo WWW equivale a un URI, Uniform Resource Identfier, (identificatore uniforme di risorse). Quindi tutte le risorse devono essere identificate univocamente a livello globale per mezzo di apposito URI. L’utilizzo di un metodo predefinito e consistente di assegnare identificativi univoci genera tutta una serie di vantaggi. In primo luogo non è necessario ogni volta inventarsi uno schema, giacche’ questo esiste già, è largamente utilizzato su scala mondiale, non presenta problemi, tutti sono in grado di comprenderlo ed è uno standard internazionale. Inoltre, risorse identificate attraverso un URI sono di fatto un link che è possibile condividere con diverse persone (per esempio inviandolo attraverso una e-mail). Insomma è evidente che identificare univocamente le risorse attraverso l’URI, oltre a essere un metodo standard, fornisce tutta una serie di importanti vantaggi. Dall’analisi degli esempi precedenti si può notare che l’indirizzo URI, in prima analisi, è composto da una parte fissa e da una parte variabile che identifica la specifica istanza. Ora, mentre la parte fissa è pressoche’ definita, per la parte variabile il suggerimento consiste nell’utilizzare un id generato dal sistema (per esempio un sequence number). A questo punto è utile enfatizzare la potenza degli ID espressi in termini di URI. In particolare questi sono link a risorse che possono essere fornite da processi, applicazioni, sever sparsi per il mondo: URI esprimono link secondo uno standard

globale.

A questo punto dovrebbe essere chiaro su cosa si intenda con il termine risorsa anche se in informatica questo vocabolo è utilizzato con diversi significati. Di certo in questo contesto non si fa riferimento a risorse fisiche come microprocessori, memorie, stampanti, o simili. Molto pragmaticamente le risorse sono le principali astrazioni ossia gli "oggetti" che il servizio intende esporre. Qualora si partisse dal disegno di un diagramma delle classi rappresentante il business oggetto di studio (modello tipicamente detto "Domain Object Model"), allora gli oggetti (ossia le classi) principali presenti in tale modello, verosimilmente, potrebbero diventare risorse in termini REST.

2.4.6 Livello 2

Come visto nel paragrafo precedente, gli URI sono molto potenti sia perche’ permettono di individuare una risorsa messa a disposizione da un server ubicato in qualsiasi parte del mondo, sia perché i browser sono in grado di effettuare la richiesta e di interpretare in qualche modo la risposta. Questo è possibile grazie all’esistenza di un altro standard: i "verbi" HTTP. Da notare che durante i primissimi anni della programmazione web, le comunicazioni client server si basavano quasi esclusivamente sul metodo HTTP GET, che veniva utilizzato per fare quasi tutto: reperire dati, inviare form da memorizzare, etc. Al GET, in alcuni casi, si preferiva il metodo POST, quando ci si imbatteva in alcune limitazione del metodo GET, come la dimensione limitata per l’invio dati. Le cose, da allora, si sono evolute tanto che il livello 2 richiede di utilizzare i metodi HTTP standard GET, PUT, POST, DELETE, in modo congruente. Il metodo GET serve per recuperare tutte le informazioni, sotto forma di un’entità, relative alla risorsa identificata

dal URI presente nella richiesta. Se l’URI richiesto si riferisce a un processo, allora la risposta deve contenere un’entità che contenga a sua volta i risultati dell’esecuzione del suddetto processo invece di restituire le informazioni relative al processo stesso. Il metodo POST è utilizzato per permettere ai client di inviare una richiesta a un server contenente dati. Gli scenari tipici sono l’uploading dei file, l’invio di form compilate al lato client, l’invio di un commento a un blog, etc. Rispetto al metodo GET, dove solo un URL e le intestazioni possono essere presenti, il metodo POST può anche includere la parte body. Ciò permette di superare il vincolo sulle dimensioni proprio del metodo GET, consentendo a questo metodo di includere una quantità arbitraria di dati di qualsiasi tipo da inviare al sever. Il metodo POST è stato studiato per permettere un metodo uniforme di svolgere le seguenti funzioni: annotazione delle risorse esistenti; invio di un messaggio a una bacheca elettronica, newsgroup, mailing list, e similari; fornitura di un blocco di dati, come per esempio una form debitamente compilata, a un processo di gestione dei dati; invio dei dati da aggiungere a un database. Una richiesta PUT serve per richiedere che l’entità racchiusa nella richiesta stessa sia memorizzata dal server destinatario (server indirizzato dall’URI). Se la richiesta si riferisce a una risorsa già esistente, allora questa deve essere interpretata come una richiesta di modifica, pertanto l’entità inviata rappresenta una versione aggiornata della corrispondente presente sul server. Se l’URI della richiesta non punta a una risorsa esistente, e se l’URI è in grado di essere definito come una nuova risorsa dal client, il server destinatario può creare la nuova risorsa con lo specifico URI. Le richieste DELETE servono per comunicare al server di eliminare la risorsa identificata dall’URI incapsulato nella richiesta stessa. Questo metodo può essere sovrascritto da un intervento umano (o da altri mezzi) sul server. Il client non ha garanzia che l’operazione sia stata eseguita,

anche se il codice di stato restituito dal server indica che l’azione è stata completata con successo. Tuttavia, il server dovrebbe restituire un codice di successo solo se, al momento in cui viene preparata la risposta, il server intenda effettivamente eliminare la risorsa o spostarla in una posizione non più accessibile.

2.4.7 Livello 3

L’ultimo livello del modello di maturità REST è costituito dai "controlli ipermediali" (Hypermedia Controls). Il termine "ipermedia" (hypermedia) è stato coniato da Ted Nelson e si riferisce alla logica estensione del termine"ipertesto" (hypertext) in cui grafica, audio, video, testo e collegamenti ipertestuali si intrecciano per creare un genere non-lineare di media di informazione.

Per raggiungere questo livello è necessario soddisfare il vincolo noto con l’acronimo, forse non felicissimo di HATEOAS, HyperText As The Engine Of Application State ("ipertesto come motore dello stato delle applicazioni"). Il principio stabilisce che un client interagisce con un’applicazione di rete interamente attraverso ipermedia forniti dinamicamente dal server. Un client REST pertanto non ha bisogno di conoscere preliminarmente come interagire con una particolare applicazione o con un server; tutto quello di cui ha bisogno è una conoscenza generica degli hypermedia. Uno stile diametralmente opposto a questo è costituito, per esempio, dalle architetture orientate ai servizi (SOA), in cui i client e i server interagiscono attraverso un’interfaccia fissa, ben definita e documentata e implementata attraverso un linguaggio di descrizione dell’interfaccia (come WSDL, Schema XML, IDL, etc.).

server di evolvere autonomamente le proprie funzionalità. Al fine di rispettare questo vincolo, il server deve restituire nella risposta anche l’insieme delle possibili azioni richiedibili.

In ogni caso, è evidente che attraverso l’utilizzo di controlli ipermediali è possibile creare un ulteriore livello di indirezione tra client e server caratterizzato dal fatto che il server possa cambiare i propri link a proprio piacimento senza inficiare il funzionamento dei propri client. Tuttavia, non è un disaccoppiamto totale giacche’ deve esistere un accordo implicito tra client e server sul nome delle azion (per esempio "reserve", "verify", etc.), e il client e il server devono convenire sui metodi da utilizzare per le future richieste (per esempio mentre "reserve" richiede un’azione POST, per eseguire l’azione verify è sufficiente un GET).

Questo vincolo, infine, permette al server di pubblicare nuove azioni senza creare problemi ai client esistenti.