L’acronimo REST (REpresentational State Transfer) definisce l’insieme di linee guida utilizzate per la realizzazione di Web Service in ambienti distribuiti. L’espressione “REpresentational State Transfer” è stata utilizzata per la prima volta nell’anno 2000, all’interno della tesi di dottorato di Roy Fielding, uno dei principali autori delle specifiche dell’Hypertext Transfer Protocol (HTTP).

I principi esposti da Fielding non ottennero inizialmente un grande successo, tuttavia, negli ultimi anni l’approccio REST è tornato alla ribalta, diventando una delle principali metodologie per la realizzazione di Web Service efficienti e scalabili.

REST, a differenza di SOAP, non costituisce un protocollo per lo scambio di messaggi, bensì un insieme di principi architetturali per la progettazione di sistemi (non esiste comunque uno standard “ufficiale” per la realizzazione di API di RESTful). Secondo la teoria di Fielding: il web dispone di tutti gli strumenti necessari per essere considerato alla stregua di una gigantesca piattaforma di elaborazione dati distribuita (secondo i principi REST), non sono quindi necessarie ulteriori sovrastrutture per realizzare il “web programmabile”. Tale definizione sottolinea l’antagonismo esistente tra i principi REST e, ad esempio, i principi SOAP.

Le linee guida proposte dalle specifiche REST possono essere così riassunte:

  • Client-Server, l’architettura REST sposa il paradigma SoC (“Separation of Concerns”, letteralmente “separazione dei compiti”). Secondo tale paradigma i client non dovranno preoccuparsi del salvataggio delle informazioni (che rimarranno memorizzate all’interno dei server), mentre i server non dovranno preoccuparsi, ad esempio, di fornire all’utilizzatore finale un’interfaccia grafica, oppure di memorizzare lo stato fornito al client. In questo modo sarà più facile realizzare server scalabili e con architetture più semplici;
  • Stateless, la comunicazione client-server è impostata in modo tale da non richiedere il salvataggio nel server di alcuna informazione (stato) legata al client. Ogni richiesta effettuata dal client dovrà contenere tutte le informazioni necessarie all’erogazione del servizio. Lo stato della singola sessione verrà custodito all’interno del client. Eliminando la necessità di memorizzare e di sincronizzare gli stati (ad esempio in ambiente cluster) si ottiene un miglioramento delle prestazioni e una naturale predisposizione alla scalabilità;
  • Cacheable, al fine di risparmiare tempo e risorse i client possono eseguire il caching delle risposte fornite dai server. Sfortunatamente, non tutte le risposte si prestano ad essere memorizzate e riutilizzate (alcune informazioni hanno una scadenza naturale). La specifica di tali limiti temporali dovrà essere contenuta all’interno della risposta, in modo da prevenire il riutilizzo di informazioni scadute o errate. Tale funzionalità facilita la scalabilità delle performance;
  • Layered System, i client possono collegarsi a server di livello basso o intermedio (i server di livello intermedio offrono servizi di load-balancing, carche distribuite e sicurezza avanzata) senza però rendersi conto della differenza;
  • Uniform Iinterface, l’uso di interfacce uniformi facilita la separazione delle architetture, permettendone l’evoluzione asincrona.