Uno dei requisiti che dovrebbero essere soddisfatti prima di poter chiamare un'API "RESTful" è che dovrebbe essere possibile scrivere un'applicazione client generica, oltre a quella API. Con il client generico, un utente dovrebbe essere in grado di accedere a tutte le funzionalità dell'API. Un client generico è un'applicazione client che non presuppone che ogni risorsa abbia una struttura specifica oltre la struttura definita dal tipo di supporto.
Nel tuo esempio, l'applicazione client offrirebbe all'utente la possibilità di seguire i collegamenti. Gli attributi rel vengono visualizzati all'utente e l'applicazione client si aspetta che l'utente comprenda questi valori.
Quanto sopra è noto come requisito REST per avere "Hypermedia as the engine of application state" (HATEOAS). Il vantaggio è che il client non si interromperà quando il back-end modificherà i suoi valori di rel . Senza HATEOAS, l'interfaccia non è RESTful.
Ora, supponiamo di avere un'API HTTP / JSON per un negozio web e vogliamo creare un client HTML / CSS / JavaScript che offra ai nostri clienti un'esperienza utente eccellente. Sarebbe un'opzione realistica lasciare che il client sia un'applicazione client generica ? No. Vogliamo fornire un look-and-feel specifico per ogni specifico elemento di dati e ogni specifico stato dell'applicazione. Non vogliamo includere tutta la conoscenza di queste specifiche di presentazione nell'API, al contrario, il client dovrebbe definire l'aspetto e l'API dovrebbe solo trasportare i dati. Ciò implica che il client ha un accoppiamento hard-coded di elementi di risorse specifici a specifici layout e interazioni dell'utente.
Questa è la fine di HATEOAS e quindi la fine di REST? Sì e no .
Sì , perché se eseguiamo la codifica hard-code dell'API nel client, perdiamo il vantaggio di HATEOAS: le modifiche sul lato server potrebbero interrompere il client.
No , per due motivi:
- Essere "RESTful" è una proprietà dell'API, non del client. Finché è possibile, in teoria , per costruire un client generico che offra tutte le funzionalità dell'API, l'API può essere chiamata RESTful. Il fatto che i clienti non rispettino le regole non è colpa dell'API. Il fatto che un client generico abbia una pessima esperienza utente non è un problema. Perché è importante sapere che è possibile avere un client generico, se non abbiamo quel client generico? Questo mi porta al secondo motivo:
- Un'API RESTful offre ai clienti la possibilità di scegliere il modo in cui vogliono essere generici, ossia quanto resiliente ai cambiamenti lato server che vogliono essere. I client che devono fornire un'esperienza utente ottimale possono comunque essere resilienti alle modifiche URI, alle modifiche dei valori predefiniti e altro ancora. I client che eseguono lavori batch senza l'interazione dell'utente possono essere resilienti ad altri tipi di modifiche.
Se sei interessato ad esempi pratici, consulta il mio documento JAREST . L'ultima sezione riguarda HATEOAS. Vedrai che con JAREST, anche i client altamente interattivi e visivamente attraenti possono essere abbastanza resilienti alle modifiche sul lato server, anche se non al 100%.