Tornando ancora una volta all'acronimo REST, REpresentational State Transfer, notiamo che in esso viene fatto riferimento al trasferimento di stato, cioè al fatto che un'applicazione passi da uno stato all'altro.
Uno dei principi REST suggerisce l'uso di collegamenti tra risorse come modalità di transizione da uno stato all'altro. Questo principio è noto anche con l'acronimo HATEOAS, Hypermedia As The Engine Of Application State, e focalizza l'attenzione sull'utilizzo dei collegamenti ipertestuali, anzi ipermediali, come meccanismo di base per far passare un'applicazione da uno stato ad un altro.
Nella visione REST, l'esecuzione di un'applicazione può essere rappresentata da una rete di risorse in cui un client naviga seguendo i collegamenti ammissibili tra una risorsa e l'altra. Questa visione probabilmente ci suonerà abbastanza familiare, dal momento che la mettiamo in pratica tutti i giorni navigando tra le pagine del Web.
Concettualmente corrisponde ad una macchina a stati finiti in cui gli stati sono rappresentati dallo stato delle singole risorse e le transizioni da uno stato all'altro sono attivate dai collegamenti ipermediali.
Il principio che sancisce il legame tra transizioni di stato e collegamenti tra risorse è purtroppo scarsamente sfruttato nelle attuali implementazioni di Web service di tipo RESTful. La maggior parte di queste implementazioni si limita a definire le rappresentazioni delle risorse e le modalità di interazione tramite i metodi HTTP.
Se il risultato di una interazione con il server è un contenitore di risorse, allora all'interno della risorsa abbiamo gli URI delle risorse contenute, altrimenti nella maggior parte dei casi non si hanno altri collegamenti. Non possiamo dire che un Web Service di questo tipo non sia RESTful, ma nella maggior parte dei casi non sfrutta a pieno le potenzialità dei principi REST.
Il principio HATEOAS, infatti, intende incoraggiare non solo l'uso di collegamenti per rappresentare risorse composte, ma anche per definire qualsiasi altra relazione tra le risorse e per controllare le transizioni ammissibili tra uno stato e l'altro dell'applicazione.
Per fare un esempio, consideriamo la seguente rappresentazione di un ordine nel nostro ipotetico negozio online :
<ordine xmlns="http://schemi.mionegozio.com/ordine">
<id>123</id>
<data>01/07/2011</data>
<cliente>Mario Rossi</cliente>
<stato>EVASO</stato>
<dettagli>
<dettaglio>
<articolo>Libro</articolo>
<quantita>1</quantita>
</dettaglio>
<dettaglio>
<articolo>CD</articolo>
<quantita>5</quantita>
</dettaglio>
</dettagli>
</ordine>In esso non è riportato alcun collegamento con altre risorse gestite dal sistema. Come può un client
conoscere la fattura associata a quest'ordine? Dovrà effettuare un'apposita richiesta al Web Service, ma dovrà conoscere l'URI della risorsa. Le specifiche del particolare Web Service potrebbero spiegare (allo sviluppatore) come fare ad ottenere la fattura di un determinato ordine, ma la cosa più naturale nell'ottica del principio HATEOAS sarebbe di includere un collegamento direttamente nella rappresentazione dell'ordine:
<ordine xmlns="http://schemi.mionegozio.com/ordine">
<id>123</id>
<data>01/07/2011</data>
<cliente>Mario Rossi</cliente>
<stato>EVASO</stato>
<dettagli>
<dettaglio>
<articolo>Libro</articolo>
<quantita>1</quantita>
</dettaglio>
<dettaglio>
<articolo>CD</articolo>
<quantita>5</quantita>
</dettaglio>
</dettagli>
<link rel="fattura" mediaType="application/xml"
href="http://www.mionegozio.com/fatture/?id=789" />
</ordine>In questo modo il client ha già nella rappresentazione dell'ordine tutte le informazioni necessarie per accedere alla fattura associata all'ordine. Tra l'altro, la presenza o meno del collegamento alla fattura associata all'ordine fornisce implicitamente un'altra informazione al client: se il collegamento non è presente nella rappresentazione dell'ordine vuol dire che la fattura non è ancora stata emessa, se invece è presente vuol dire che è stata emessa ed è accessibile. Questa consente un maggior controllo della transizione da uno stato all'altro dell'applicazione, evitando transizioni non ammissibili in un dato momento.
Sfruttando pienamente il principio HATEOAS è possibile creare servizi Web con scarso accoppiamento tra client e server. Infatti, se il server riorganizza le relazioni tra le risorse, il client è in grado di trovare tutto ciò che serve nelle rappresentazioni ricevute. Potenzialmente tutto quello che servirebbe ad un client è solo l'URI della risorsa iniziale, ad esempio quello dell'ordine. Come avanzare tra uno stato e l'altro dell'applicazione verrà indicato man mano che si seguono i collegamenti incorporati nelle successive rappresentazioni di risorse.