Representational State Transfer

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, 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

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 è:
  • Client-Server
  • Stateless
  • Cachable
  • A livelli

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)

Il principio fondamentale di REST: le risorse

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.

Riferimenti

• , op. cit.

• , op. cit.

• 2008-04

Collegamenti esterni

• "Introduzione al paradigma REST": introduzione, descrizione e analogie per il paradigma REST
• “Architectural Styles and the Design of Network-based Software Architectures”: Dissertation for Doctor of Philosophy, by Roy Thomas Fielding
• “RESTful Web Services with JSP”: Tutorial for easy RESTful Web Service with JSP
• RESTwiki: “descriptions of REST, records of the experiences of REST proponents, and resources to help you apply REST [...] to your software or framework”
• “Constructing or Traversing URIs?”: discusses the constraint on components to use “hypermedia as the engine of application state”.
• The REST Dialogues, Part 1: “Getting Data”: one of nine lessons on applying REST to Web-based business, each lesson in the form of dialog between the author and a fictitious senior technical employee of a company conducting Web-based business.
• “REST for the Rest of Us”: “showcases common REST design patterns that can be put to immediate use”.
• “MindTouch: Introduction to REST”: slides and narration explaining REST.
• “RESTify DayTrader”: a tour of a day-trading interface in REST style.
• “Building Web Services the REST Way”
• "InfoQ: A Brief Introduction to REST"
• "How I Explained REST to my Wife"

Portale Telematica

Portale Web