«

»

Ott 23

A proposito di REST

Sto valutando se realizzare un webservice secondo l’architettura REST oppure no.

Dalla tesi di dottorato di Roy Fielding, inventore di REST (REpresentational State Transfer)

Dobbiamo poi aggiungere un vincolo per l’interazione client-server: la comunicazione deve essere «senza stato» di natura, come nello stile senza stato client-server (CSS) del paragrafo 3.4.3 (Figura 5-3), in modo tale che ogni richiesta dal client al server debba contenere tutte le informazioni necessarie per capire la richiesta, e non possa sfruttare qualsiasi contesto memorizzato sul server. Lo stato della sessione viene quindi mantenuto interamente sul client.

Figure 5.2: Client-Server

Figure 5.3: Client-Server (Fonte http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)

 

Questo vincolo induce le proprietà di visibilità, affidabilità e scalabilità. La visibilità è migliorata perché un sistema di monitoraggio non deve guardare oltre un singolo dato di richiesta per determinare la natura esaustiva della richiesta.1 L’affidabilità risulta migliorata in quanto facilita il compito di recupero da guasti parziali [133]2. La scalabilità è migliorata perché non dovendo memorizzare lo stato tra una richiesta e l’altra, si consente al componente server di liberare rapidamente risorse e, inoltre, ne semplifica l’attuazione in quanto il server non deve gestire l’utilizzo delle risorse a cavallo tra le richieste.3

 

1 Si pensi ad esempio da un analizzatore di log di Apache con il quale si voglia capire un caso di sovraccarico del server: se l’applicazione non è REST, la risorsa che viene restituita da un URI (assieme a quanto processore e quanta memoria vengono impiegati per servire tale risorsa) non è necessariamente determinata a partire dai parametri dell’URI, se ciò che viene restituito dipende anche da uno stato del server; cioè, in base allo stesso URI, il server può restituire risorse diverse in base al diverso stato che viene incontrato nel server in due chiamate successive.
2 Ad esempio, sempre nel caso di malfunzionamento tra due chiamate successive, che implicano un diverso stato del server, è difficile stabilire stando fuori dal server quale sia la natura del problema (si pensi a quando una sessione scade: uno stesso url prima funziona e poi no, ma per sapere il perché dobbiamo entrare nel server). Inoltre un errore occorso durante una richiesta non influenza le altre richieste.
3 Letto in altro modo, siccome il servizio di una richiesta implica un minor consumo di risorse, il server può servire più velocemente e più in parallelo, aumentando così la scalabilità.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Puoi usare i seguenti tag ed attributi HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>