In questo ultimo post sul modello REST voglio provare a rispondere ad una semplice domanda: perché dovremmo rimanere fedeli al modello REST quando realizziamo applicazioni web?
Per farlo dobbiamo partire dagli obiettivi che questa architettura si pone:
scalabilità geografica; adozione di interfacce generiche (es.: HTTP, URI, ecc.) condivise tra tutti i client e server; deploy indipendente dei componenti (es.: siti web, web app, browser, motori di ricerca, ecc.); adozione di middleware per ridurre la latenza delle interazioni (es.
Nel precedente post vi ho raccontato delle vicende che hanno portato alla definizione del modello REST. Non è il caso di entrare nel merito della descrizione, piuttosto formale, che ne fa l’autore nella sua tesi di dottorato. Vediamo invece quali sono i concetti chiave di questa architettura e come questi siano riscontrabili nel Web e più di recente abbiano ispirato i servizi RESTful*.
Risorse e identificativi Nel modello REST si parla di risorse e dei relativi identificativi, che corrispondono nel Web ai documenti (html, jpg, css, ecc.
Chiacchierando tra colleghi mi sono accorto che chi viene dal mondo SOAP e si avvicina ai servizi RESTful commette spesso l’errore di pensare che la principale differenza tra i due approcci sia solo la notazione utilizzata per lo scambio dei dati, XML per i servizi SOAP e JSON per quelli RESTful. Per avere un’idea più corretta sui concetti alla base di questi servizi è necessario fare un salto nel passato e seguire la nascita del Web per come lo conosciamo adesso.
