Abbiamo sottolineato come le risorse giocano un ruolo fondamentale nell'approccio REST ed abbiamo visto come identificarle e come gestirle. Ma come sono rappresentate?
Risorse autodescrittive
Le risorse di per sè sono concettualmente separate dalle rappresentazioni restituite al client. Ad esempio, un Web Service non invia al client direttamente un record del suo database, ma una sua rappresentazione in una codifica dipendente dalla richiesta del client e/o dall'implementazione del servizio.
I principi REST non pongono nessun vincolo sulle modalità di rappresentazione di una risorsa. Virtualmente possiamo utilizzare il formato che preferiamo senza essere obbligati a seguire uno standard. Di fatto, però, è opportuno utilizzare formati il più possibile standard in modo da semplificare l'interazione con i client. Inoltre, sarebbe opportuno prevedere rappresentazioni multiple di una risorsa, per soddisfare client di tipo diverso.
Il tipo di rappresentazione inviata dal Web Service al client è indicato nella stessa risposta HTTP tramite un tipo MIME, così come avviene nella classica comunicazione tra Web server e browser.
Un client a sua volta ha la possibilità di richiedere una risorsa in uno specifico formato sfruttando l'attributo Accept di una richiesta HTTP di tipo GET, come mostrato nel seguente esempio:
GET /clienti/1234 HTTP/1.1 Host: www.myapp.com Accept: application/vnd.myapp.cliente+xml
In questo caso il client richiede la rappresentazione del cliente con id 1234, in formato XML secondo lo schema definito da vnd.myapp.cliente. Se il Web Service lo supporta, la stessa risorsa può essere richiesta in formati diversi, come ad esempio JSON o HTML.
La possibilità di rappresentazioni multiple produce alcuni benefici pratici: ad esempio, se abbiamo un output sia HTML, sia XML, possiamo consumare il servizio sia con un'applicazione sia con un comune browser. In altre parole, seguendo i principi REST nel progettare un'applicazione Web è possibile costruire sia una Web API che una Web UI.
Collegamenti tra risorse
Un altro vincolo dei principi REST consiste nella necessità che le risorse siano tra loro messe in relazione tramite link ipertestuali. Questo principio è anche noto come HATEOAS, dall'acronimo di Hypermedia As The Engine Of Application State, e pone l'accento sulle modalità di gestione dello stato dell'applicazione.
In sostanza, tutto quello che un client deve sapere su una risorsa e sulle risorse ad essa correlate deve essere contenuto nella sua rappresentazione o deve essere accessibile tramite collegamenti ipertestuali.
Ad esempio, la rappresentazione di un ordine in un linguaggio XML-based deve contenere gli eventuali collegamenti agli articoli ed al cliente correlati:
<ordine>
<numero>12345678</numero>
<data>01/07/2011</data>
<cliente rif="http://www.myapp.com/clienti/1234" />
<articoli>
<articolo rif="http://www.myapp.com/prodotti/98765" />
<articolo rif="http://www.myapp.com/prodotti/43210" />
</articoli>
</ordine>In questo modo il client può accedere alle risorse correlate seguendo semplicemente i collegamenti contenuti nella rappresentazione della risorsa corrente.
Il fatto di utilizzare un URI come identificatore di una risorsa, quindi un meccanismo standard e consolidato, consente al client di accedere anche a risorse messe a disposizione da altre applicazioni che girano eventualmente su altri server.
Inoltre, la possibilità di avere collegamenti ipertestuali all'interno della rappresentazione di una risorsa rappresenta un meccanismo per poter gestire lo stato dell'applicazione, come vedremo in seguito.
Comunicazione senza stato
Il principio della comunicazione stateless è ben noto a chi lavora con il Web.
Questa è infatti una delle caratteristiche principali del protocollo HTTP, cioè ciascuna
richiesta non ha alcuna relazione con le richieste precedenti e successive. Lo stesso principio si applica
ad un Web Service RESTful, cioè le interazioni tra client e server devono essere senza stato.
È importante sottolineare che sebbene REST preveda la comunicazione stateless, non vuol dire che un'applicazione non deve avere stato. La responsabilità della gestione dello stato dell'applicazione non deve essere conferita al server, ma rientra nei compiti del client.
La principale ragione di questa scelta è la scalabilità: mantenere lo stato di una sessione ha un costo in termini di risorse sul server e all'aumentare del numero di client tale costo può diventare insostenibile. Inoltre, con una comunicazione senza stato è possibile creare cluster di server che possono rispondere ai client senza vincoli sulla sessione corrente, ottimizzando le prestazioni globali dell'applicazione.