- Learn
- RESTful Web Services – La Guida
- Gestire la comunicazione stateless
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.
Se vuoi aggiornamenti su Gestire la comunicazione stateless inserisci la tua email nel box qui sotto:
Compilando il presente form acconsento a ricevere le informazioni relative ai servizi di cui alla presente pagina ai sensi dell'informativa sulla privacy.
La tua iscrizione è andata a buon fine. Se vuoi ricevere informazioni personalizzate compila anche i seguenti campi opzionali:
Compilando il presente form acconsento a ricevere le informazioni relative ai servizi di cui alla presente pagina ai sensi dell'informativa sulla privacy.
I Video di HTML.it
Elogio a AngularJS 1.x
Dopo l’uscita di Angular 2 molti si troveranno a dover decidere se migrare tutti i progetti realizzati con Angular JS […]