Per chi è abituato a lavorare con sistemi centralizzati, costituiti ad esempio da una applicazione monolitica dotata di un unico database relazionale, la realizzazione di un sistema distribuito si presenta ricca di insidie. Ne facevo cenno già in un precedente post in cui cercavo di far luce sui problemi che l’astrazione offerta dai moderni strumenti riesce a nascondere ma non a risolvere del tutto. Uno di questi problemi è legato al concetto di consistenza dei dati sparsi in un sistema distribuito.
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.
Quando sviluppiamo tendiamo a trascurare gli aspetti legati al momento dell’esecuzione del codice, al così detto runtime. Questo capita maggiormente quando si ha a che fare con i linguaggi di alto livello, magari a macchina virtuale come il Java che “gira” all’interno di una JVM o il C# eseguito da una CLR, ma anche con i linguaggi di scripting come il PHP interpretato ed eseguito dallo Zend Engine. Questi ambienti di runtime infatti operano dietro le quinte, ad esempio gestendo in maniera trasparente l’allocazione dinamica della memoria.
