Representational State Transfer

Da Wikipedia, l'enciclopedia libera.

REpresentational State Transfer (REST) è un tipo di architettura software per i sistemi di ipertesto distribuiti come il World Wide Web. I termini "representational state transfer" e "REST" furono introdotti nel 2000 nella tesi di dottorato di Roy Fielding,[1] uno dei principali autori delle specifiche dell'Hypertext Transfer Protocol (HTTP), termine ampiamente usato nella comunità di Internet.

REST si riferisce ad un insieme di principi di architetture di rete, i quali delineano come le risorse sono definite e indirizzate. Il termine è spesso usato nel senso di descrivere ogni semplice interfaccia che trasmette dati su HTTP senza un livello opzionale come SOAP o la gestione della sessione tramite i cookie. Questi due concetti possono andare in conflitto così come in sovrapposizione. È possibile progettare ogni sistema software complesso in accordo con l'architettura REST di Fielding senza usare HTTP e senza interagire con il World Wide Web. È anche possibile progettare una semplice interfaccia XML+HTTP che non sia conforme ai principi REST, e invece segua un modello di Remote Procedure Call. La differenza tra l'uso del termine "REST" quindi causa qualche confusione nei dibattiti.

I sistemi che seguono i principi REST sono spesso definiti "RESTful".

Principi[modifica | modifica wikitesto]

REST prevede che la scalabilità del Web e la crescita siano diretti risultati di pochi principi chiave di progettazione:

  • Lo stato dell'applicazione e le funzionalità sono divisi in risorse web
  • Ogni risorsa è unica e indirizzabile usando sintassi universale per uso nei link ipertestuali
  • Tutte le risorse sono condivise come interfaccia uniforme per il trasferimento di stato tra client e risorse, questo consiste in:
    • un insieme vincolato di operazioni ben definite
    • un insieme vincolato di contenuti, opzionalmente supportato da codice on demand
  • un protocollo che è:

Fielding descrive l'effetto dell'architettura REST sulla scalabilità in questo modo:

« REST’s client-server separation of concerns simplifies component implementation, reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and increases the scalability of pure server components. Layered system constraints allow intermediaries—proxies, gateways, and firewalls—to be introduced at various points in the communication without changing the interfaces between components, thus allowing them to assist in communication translation or improve performance via large-scale, shared caching. REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability. »
(Fielding, op. cit., 2000)

Vincoli[modifica | modifica wikitesto]

L'approccio architetturale REST è definito dai seguenti sei vincoli applicati ad una architettura, mentre si lascia libera l'implementazione dei singoli componenti.

Client–server. Un insieme di interfacce uniformi separa i client dai server. Questa separazione di ruoli e preoccupazioni significa che, per esempio, il client non si deve preoccupare del salvataggio delle informazioni, che rimane all'interno di ogni singolo server, in questo modo la portabilità del codice del client ne trae vantaggio. I server non si devono preoccupare dell'interfaccia grafica o dello stato dell'utente, in questo modo i server sono più semplici e maggiormente scalabili. Server e client possono essere sostituiti e sviluppati indipendentemente fintanto che l'interfaccia non viene modificata.

Stateless. La comunicazione client–server è ulteriormente vincolata in modo che nessun contesto client venga memorizzato sul server tra le richieste. Ogni richiesta da ogni client contiene tutte le informazioni necessarie per richiedere il servizio, e lo stato della sessione è contenuto sul client. Nota importante lo stato della sessione può essere trasferito al server attraverso un altro servizio posto a persistere ad esempio lo stato su database.

Cacheable. Come nel World Wide Web, i client possono fare caching delle risposte. Le risposte devono in ogni modo definirsi implicitamente o esplicitamente cacheable o no, in modo da prevenire che i client possano riusare stati vecchi o dati errati. Una gestione ben fatta della cache può ridurre o parzialmente eliminare le comunicazioni client server, migliorando scalabilità e performance.

Layered system. Un client non può dire se è connesso direttamente ad un server di livello più basso od intermedio, i server intermedi possono migliorare la scalabilità del sistema con load-balancing o con cache distribuite. Layer intermedi possono offrire inoltre politiche di sicurezza

Code on demand. (opzionale) I server possono temporaneamente estendere o personalizzare le funzionalità del client trasferendo del codice eseguibile. Ad esempio questo può includere componenti compilati come Applet Java o linguaggi di scripting client side come JavaScript. "Code on demand" è l'unico vincolo opzionale per la definizione di un'architettura REST.

Uniform interface. Un'interfaccia di comunicazione omogenea tra client e server permette di semplificare e disaccoppiare l'architettura, la quale si può evolvere separatamente.

Il principio fondamentale di REST: le risorse[modifica | modifica wikitesto]

Un concetto importante in REST è l'esistenza di risorse (fonti di informazioni), a cui si può accedere tramite un identificatore globale (un URI). Per utilizzare le risorse, le componenti di una rete (componenti client e server) comunicano attraverso una interfaccia standard (ad es. HTTP) e si scambiano rappresentazioni di queste risorse (il documento che trasmette le informazioni). Ad esempio, una risorsa cerchio potrebbe accettare e restituire una rappresentazione che specifica un punto per il centro e il raggio, formattati nel formato SVG, ma potrebbe anche accettare e restituire una rappresentazione che specifica tre punti distinti qualsiasi lungo la circonferenza nel formato CSV.

Un numero qualsiasi di connettori (client, server, cache, tunnel ecc.) può mediare la richiesta, ma ogni connettore interviene senza conoscere la “storia passata” delle altre richieste. Di conseguenza una applicazione può interagire con una risorsa conoscendo due cose: l'identificatore della risorsa e l'azione richiesta - non ha bisogno di sapere se ci sono proxy, gateway, firewalls, tunnel, ecc tra essa e il server su cui è presente l'informazione cercata. L'applicazione comunque deve conoscere il formato dell'informazione (rappresentazione) restituita, tipicamente un documento HTML, XML o JSON, ma potrebbe essere anche un'immagine o qualsiasi altro contenuto.

Note[modifica | modifica wikitesto]

  1. ^ Il capitolo 5 della tesi di Fielding è intitolato “Representational State Transfer (REST)”.

Riferimenti[modifica | modifica wikitesto]

Collegamenti esterni[modifica | modifica wikitesto]