Negli ultimi anni le applicazioni web basate su servizi hanno conosciuto una notevole espansione, coadiuvate dall'avvento di tecnologie lato server specifiche, come ad esempio WCF, e, lato client, dalla maturità ormai raggiunta da tecnologie quali AJAX, Silverlight e Flash.

Tuttavia parlare di servizi porta generalmente ed erronamente a parlare di web service. In realtà i servizi sono concettualmente un qualcosa di più astratto ed i web service ne rappresentano la casistica più conosciuta. Possiamo definire un servizio come un'interfaccia pubblica che dà accesso ad una o più funzionalità sulla rete: il client che fa uso di queste funzionalità è esclusivamente un fruitore del servizio stesso e non ne conosce l'implementazione. Client e servizio sono completamente disgiunti e, tipicamente, attivi in nodi fisici diversi e interagiscono tra loro tramite lo scambio di messaggi, siano questi testuali o binari, il cui formato viene scelto in base a diversi fattori, quali il protocollo di comunicazione (per esempio, SOAP) o le tecnologie scelte per l'implementazione.

In contrapposizione ai web service SOAP, una particolare implementazione di applicazione web basata su servizi è quella rappresentata dai RESTful web service, i quali hanno acceso negli ultimi tempi un vero e proprio dibattito sulla reale necessità dei web service e del loro utilizzo talvolta smodato.

L'obiettivo di questo articolo è quello di focalizzare l'attenzione su una soluzione di questo tipo, fornendo gli elementi chiave per valutarne gli aspetti principali, e illustrare come questa possa essere legata ad un'implementazione basata su ASP.NET MVC 2, beneficiando delle peculiarità del framework.

REST contro tutti

Un RESTful web service adopera il paradigma REST (acronimo di REpresentational State Transfer). Tale paradigma è basato su alcuni punti cardine:

• Separation-of-concerns: client e server sono nettamente separati. Ad esempio, il client non si occupa della persistenza dei dati, che rimane una prerogativa lato server, ma non si occupa principalmente dell'interfaccia utente.
• Stateless: il server non conserva informazioni di stato tra una richiesta e l'altra, ma si occupa solo di gestirle come entità uniche.
• Cacheable: le risposte sono "cache-abili" e contengono al loro interno definizioni implicite o esplicite relative all'utilizzo della cache da parte del client.
• Sistema stratificato: un client non ha conoscenza diretta del server a cui è collegato, né di come questo ottiene le informazioni richieste. Questo comporta notevoli vantaggi in termini di scalabilità dell'architettura.
• Interfaccia uniforme: avere un'interfaccia uniforme tra client e server semplifica l'architettura, consentendo inoltre sia al client che all'ambiente server di evolvere in modo indipendente tra loro.
• Identificazione delle risorse: le risorse vengono identificate in modo univoco, ad esempio usando gli URL. Le risorse stesse sono concettualmente separate dalla rappresentazione inviata al client.
• Messaggi auto descrittivi: ciascun messaggio contiene tutte le informazioni necessarie per essere processato.

E' abbastanza evidente come questo paradigma trovi il suo habitat naturale nel web esattamente come lo conosciamo. Difatti, un RESTful web service si appoggia direttamente ad HTTP come protocollo, che assume il ruolo di interfaccia uniforme come richiesto dal paradigma REST, sfruttandone i suoi verbi principali:

• GET: per ottenere una risorsa;
• POST: per creare una nuova risorsa;
• PUT: per aggiornare una risorsa;
• DELETE: per eliminare una risorsa.

Leggendo l'elenco dei verbi HTTP, possiamo notare l'assonanza con le classiche operazioni CRUD, rispettivamente SELECT, INSERT, UPDATE, DELETE.

Perché ASP.NET MVC 2?

Il pattern Model-View-Controller (MVC) è di fatto uno standard di progettazione che consiste nella separazione dell'applicazione in tre macro-categorie di componenti separate:

• il model che si occupa della definizione delle entità che intervengono nell'applicazione e definisce la business-logic;
• le view che realizzano l'interfaccia utente;
• i controller sono il "ponte" tra il model e le view, gestiscono l'interazione con l'utente, raccogliendo le richieste di quest'ultimo dalle view, interfacciandosi con il model per eseguire le operazioni necessarie a gestire le richieste.

ASP.NET MVC è l'implementazione di Microsoft di questo pattern, basata su ASP.NET, giunta alla sua seconda release (MVC 2) , mentre la terza versione (MVC 3) è in fase di sviluppo e attualmente in Preview.

Nel framework MVC ASP.NET, il model corrisponde agli oggetti dell'applicazione responsabili della logica di business, tra cui l'object-model. L'insieme degli oggetti è specifico per l'applicazione e spetta allo sviluppatore definirlo in base alle proprie esigenze ed alle specifiche funzionali.

Come da definizione, gli oggetti del modello non entrano in gioco nè durante la fase di generazione dell'output, nè nella fase di input da parte del client, che sono gli ambiti di intervento rispettivamente delle view e dei controller.

Le view si occupano esclusivamente del rendering dell'interfaccia utente appropriata utilizzando i dati provenienti dal controller, e, come previsto dal pattern, non possono e non devono contenere alcun tipo di logica di business al proprio interno.

I controller elaborano le richieste in ingresso, gestendo e, se necessario validando, gli eventuali dati di input derivanti dall'interazione utente, ed eseguendo tutta la logica necessaria per il completamento della richiesta. Un controller al suo interno definisce una serie di metodi chiamati action method, ciascuno dei quali generalmente associato univocamente ad una specifica azione dell'utente. Per meglio comprendere il meccanismo di mapping tra action method ed azioni utente, dobbiamo osservare più praticamente il ruolo dell'URL all'interno del framework ASP.NET MVC.

Figura 1 - Model-View-Controller

Il concetto di URL per gli sviluppatori web è, generalmente, direttamente riconducibile al concetto di file fisico sul web server, il quale si occupa di eseguire e servire la pagina o il file corrispondente alla richiesta che viene effettuata, secondo una corrispondenza univoca.