Gestire la comunicazione stateless

Tra i principi su cui si basano le architetture RESTful ce n’è uno abbastanza importante ma spesso poco compreso. Si tratta del principio che stabilisce la necessità di avere una comunicazione stateless, senza stato, cioè una comunicazione tra client e server in cui ciascuna richiesta è indipendente dalle altre.

Una richiesta non deve richiede al server il recupero di un contesto o stato dell’applicazione. Un Web Service o un client REST devono includere nelle intestazioni o nel corpo HTTP tutti i parametri, contesto e dati necessari al server per generare una risposta.

Una comunicazione senza stato consente di ottimizzare le prestazioni del Web Service e di semplificare la progettazione e l’implementazione dei componenti lato server, perchè l’assenza della gestione dello stato rimuove la necessità di sincronizzare dati di sessione con un’applicazione esterna.

Inoltre l’assenza di stato nella comunicazione offre la possibilità di scalare l’applicazione su più server per la distribuzione del carico di lavoro o per fault tolerance.

Il protocollo HTTP è intrinsecamente senza stato, ma molto spesso nello sviluppo di applicazioni Web vengono artificialmente ricreate le condizioni per una comunicazione con stato. Ad esempio, l’uso di chiavi di sessione, in diversi framework di sviluppo per il Web, non fa altro che introdurre lo stato della comunicazione al di sopra del protocollo HTTP, in genere sfruttando i cookie.

In una architettura RESTful l’uso di comunicazioni con stato sarebbe vietato: il server non dovrebbe tenere traccia delle relazioni tra le diverse richieste. Se è necessario gestire uno stato della comunicazione, questo è compito del client.

Stato delle risorse e dell’applicazione

Il fatto che i principi REST escludano la gestione dello stato della comunicazione non deve però far pensare che i Web Service RESTful siano senza stato. L’acronimo REST sta per REpresentational State Transfer, sottolineando proprio la centralità della gestione dello stato in un sistema distribuito. Lo stato che REST prende in considerazione è però quello delle risorse e dell’intera applicazione.

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 sever 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à.

Nella progettazione di un Web Service RESTful questa separazione dei ruoli deve essere chiara e spesso occorre ripensare opportunamente la gestione dello stato in termini di gestione di risorse.

Chiariamo questo concetto con un esempio: come viene gestito di solito un carrello in una comune applicazione di e-commerce? Tipicamente si ricorre ad una rappresentazione lato server associata alla sessione corrente dell’utente. Per quanto abbiamo detto finora, questo approccio non è RESTful, dal momento che richiede il mantenimento dello stato della sessione.

Per un approccio RESTful abbiamo a disposizione due possibili soluzioni: demandare al client il compito di gestire il carrello o gestire il carrello sul server come una risorsa.

Nel primo caso il client avrà una struttura dati in cui terrà traccia degli articoli a cui l’utente è interessato. Nel momento della generazione della richiesta di un nuovo ordine da inviare al server, gli articoli annotati nel carrello verranno riportati nell’ordine.

In alternativa è possibile che il nostro Web Service preveda una risorsa carrello dedicata al mantenimento degli articoli scelti dall’utente durante la fase di acquisto. È da sottolineare il fatto che il carrello è una risorsa come le altre e non è associata alla sessione corrente. È quindi accessibile tramite URI in qualsiasi momento, è persistente ed è gestibile tramite i metodi HTTP.

La trasformazione in risorse di elementi tradizionalmente gestiti tramite lo stato della sessione è un approccio da tenere presente durante la progettazione di un Web Service RESTful.