Sono ormai alcuni anni che mi occupo prevalentemente di sviluppo Web ed integrazione in ambienti distribuiti nell'ambito del B2B e devo dire che nel corso del tempo lo stile architetturale che mi ha convinto di più per riusabilità, scalabilità ed efficienza è REST. In questo blog ne ho parlato una volta soltanto, partendo da alcune riflessioni non troppo entusiaste di altri blogger che evidenziavano GIUSTAMENTE il fatto che REST in realtà ha costituito per molti (me compreso) un 'modus operandi' ancor prima di sapere che si chiamasse così e che fosse collegato da molto tempo ad un vero e proprio "branch ufficioso" dello sviluppo Web.
Rob Conery afferma:
"...the Web itself is the REST poster child. More accurately: REST is a state of mind..."
In effetti REST (ROA nel Web) esiste e "rivaleggia" con SOA da ormai molto tempo (una decina di anni se non di più) e da quanto ho avuto modo di osservare nella mia esperienza di sviluppatore Web, non è mai riuscito a sfondare nel mondo Enterprise in egual modo (almeno a livello di trend) rispetto al diretto concorrente. Non mi azzardo a supporre quale sia la spiegazione commerciale di questa cosa (anche perché attualmente non ho né le competenze né la conoscenza per farlo), tuttavia da quando ho iniziato a pensare REST-ful, secondo me il vero vantaggio che paga concretamente gli sforzi di implementazione ruota intorno a questo semplicissimo concetto:
Uniformare le interfacce è meglio che specializzarle
A differenza dell'approccio dei WS e in generale di SOA - ovvero promuovere appunto la specializzazione delle interfacce nonché i pattern e gli idiomi dei linguaggi di programmazione in un ambiente distribuito -, REST riduce ulteriormente l'accoppiamento funzionale tra client e server spostando il focus architetturale sulle risorse/entità, risolvendo elegantemente una marea di problemi di integrazione.
In merito, due sono principalmente le obiezioni SOA-oriented che spesso sento affermare da colleghi/blogger:
- Risorse differenti dovrebbero avere interfacce e metodi specifici affinché riflettano meglio le loro funzionalità
- REST è solo una traslazione dei problemi di (dis)accoppiamento funzionale al livello di scambio di messaggi tra client e server
Personalmente non sono molto d'accordo in entrambi i casi anzitutto perché sono convinto che gli effetti della distribuzione delle applicazioni nel Web sollevi nativamente dei problemi che possono essere risolti in maniera flessibile e scalabile solo da soluzioni REST-ful... partendo dalle "semplici" problematiche di performance (caching, latenza etc.), intermediazione (state management) e monitoraggio fino ad arrivare ai punti caldi della questione:
- Identificazione delle risorse tramite URI logici (es. http://.../myWebApp/Customers/[CustomerID]) che di fatto costituiscono una sorta di API ad alto livello di astrazione, implicando un netto miglioramento dell'accessibilità/comprensibilità/reperibilità per diverse figure professionali.
- La manipolazione delle risorse, che avviene attraverso le stesse rappresentazioni in combinazione con l'uso dei verbi HTTP (GET, POST, PUT etc.) e NON va contro i principi dell'information hiding (una rappresentazione di una risorsa non ne rivela alcun dettaglio implementativo)
- I messaggi tra client e server sono auto-descrittivi e il relativo contenuto è rappresentabile mediante un qualunque media types MIME, il che preserva nativamente lo sviluppatore dall'implementazione di codice ad-hoc per gestire specifici tipi di dati WSDL (se non IDL).
- Gli hypermedia stessi costituiscono il motore dello stato delle applicazioni: questo approccio stabilisce definitivamente che le transizioni da uno stato ad un altro di una applicazione sono ESPLICITE e si trovano proprio all'interno della rappresentazione di uno stato e non all'interno della logica di metodi specifici di una o più interfacce esposte (transizioni IMPLICITE).
Esempio: Supponiamo di avere la risorsa http://.../myWebApp/Customers/List la quale elenca la lista dei clienti mediante degli HyperLink all'interno di una pagina XHTML, ognuno dei quali punta ad un' altra specifica risorsa del tipo http://.../myWebApp/Customers/[CustomerID]. Ora, uno user agent che cerca le informazioni di uno specifico cliente ha solo il bisogno di seguire tali Hyperlink semplicemente controllando i dati e i metadati della rappresentazione della risorsa richiesta. In questo semplice caso, mantenere lo stato dell'applicazione nel client invece che sul server aumenta di molto la scalabilità.
ASP.NET e REST
Un aspetto su cui riflettere è che dopo tutto questo tempo Microsoft ha deciso di promuovere REST e ROA al 'grande pubblico', in concomitanza con l'uscita di Visual Studio 2008. Nella fattispecie, abbiamo assistito alla realizzazione di un framework ad-hoc per la creazione di applicazioni REST-ful con ADO.NET Data Services (progetto Astoria - prima come Extension e poi come feature inserita nella SP1 beta del Framework 3.5 assieme all' Entity Framework).
Ma il fatto curioso che ho avuto modo di notare nella mia esperienza è che per molti sviluppatori ASP.NET, i principi di REST sono più percepiti nel pattern MVC piuttosto che nel framework ADO.NET Data Services dedicato. Un errore concettuale? Io sinceramente penso di no.
In questo senso infatti sono assolutamente d'accordo con le riflessioni di Dino Esposito in questi due bellissimi post:
le quali mi portano a pensare che la proclamazione definitiva di REST tra gli sviluppatori ASP.NET in fondo è da attribuire ANCHE all'introduzione degli aspetti REST-like del framework MVC. In particolare, ecco alcune frasi che mi sono piaciute molto:
So what's IMHO the main aspect of the MVC framework? It uses a REST-like approach to ASP.NET Web development. It implements each request to the Web server as an HTTP call to something that can be logically described as a "remote service endpoint". .... I see more REST than MVC in this model. And, more importantly, REST is a more appropriate pattern to describe what pages created with the MVC framework actually do.
E non è finita qui: oggi si possono prendere 'pezzi' dell' architettura ASP.NET MVC e fonderli nello sviluppo dei tradizionali Web Form (Classic ASP.NET). Ad esempio, il Routing delle Url (System.Web.Routing) del framework MVC può essere calato nello sviluppo ASP.NET per implementare URL logiche in perfetto REST-style (ecco un esempio).
Mumble Mumble.... Domanda: Classic ASP.NET e ASP.NET MVC Framework possono fondersi nel nome di REST ???
Se così fosse, ci troveremmo di fronte ad una situazione in cui, da un lato lo sviluppo ASP.NET viene fatto tendere verso soluzioni REST-ful by Design e dall'altro si rischia di 'sporcare' le best practice architetturali di REST e ROA magari per 'accomodare' soltanto alcuni aspetti specifici del mondo MVC nel mondo Classic ASP.NET (basato sul Postback model).
Da perenne e incondizionato sostenitore di REST come standard de facto per l'accesso e l'elaborazione delle risorse nel Web, non posso che apprezzare gli sforzi di Microsoft degli ultimi tempi (e ritengo anche che varrebbe la pena investirci seriamente soprattutto nel settore Systems Integration) ma non posso neanche nascondere delle riserve sul grande ritardo che il paradigma ha avuto per quanto riguarda l'integrazione in Visual Studio ed in particolare in ASP.NET.
Technorati tags: 
REST, 
Astoria, 
MVC, 
ASP.NET