ASP.NET MVC Web API, è un framework per lo sviluppo di servizi RESTful basati su protocollo HTTP, che ne sfrutta la versatilità e portabilità, aggiungendo la versatilità di MVC, la potenza dei linguaggi e del .NET Framework. Si tratta di un componente incluso in ASP.NET MVC 4 e, pertanto, per sfruttarne le potenzialità, è sufficiente installare l'ultima versione di ASP.NET MVC tramite Web Platform Installer.

ASP.NET Web API: breve storia

Le Web API inizialmente esordirono come parte di Windows Communication Fundation, dapprima come WCF REST Startet Kit e successivamente come WCF Web API; questi framework consentivano di esporre un endpoint WCF-REST su HTTP. Allo stesso tempo anche il team di ASP.NET MVC si era attrezzato per gestire scenari RESTFul, per esempio mediante la manipolazione e il ritorno di dati in formato JSON dalla acion di un controller. Questa sovrapposizione fù tuttavia temporanea, fino a quando i due team WCF e ASP.NET vennero aggregati per concentrare i loro sforzi, consegnando agli sviluppatori quello che oggi va sotto il nome di ASP.NET Web API.

ASP.NET Web API ha inglobato e sostituito WCF Web API, divendando il framework di riferimento (almeno per chi usa i tool di Microsoft) per la scrittura ed il consumo di servizi RESTful.

Le Web API erano inizialmene disponibili mediante installazione separata, da qualche tempo sono parte integrante e distribuite con ASP.NET MVC 4, per cui è possibile partire da un template specifico di progetto in Visual Studio, a partire dalla versione 2010.

REST VS SOAP

Il paradigma REST è tuttaltro che recente: è stato formalizzato nel 2000 da Roy Ferling, uno degli autori delle specifiche dello standard HTTP, che aveva l'ambizione e l'intento di definire uno standard per l'identificazione, l'indirizzamento e la manipolazione di risorse, nello specifico "dati", mediante il protocollo HTTP.

Potremmo affermare che REST è il paradigma nativo e semplificato, per lo scambio di dati sul web con HTTP.

Ad oggi esistono diversi paradigmi e architetture software, che assolvono lo stesso compito, in alcuni casi si tratta di veri e propri standard, nati per lo sviluppo di servizi e lo scambio dei dati, come ad esempio i web service SOAP.

Questo standard utilizza uno modalità differente, rispetto a REST, per lo scambio dei dati che sono rappresentati in formato XML, secondo un approccio Object Oriented, con possibilià di sfruttare più protocolli per il trasporto, tra cui anche HTTP. Le problematiche affrontate e risolte da SOAP, tipicamente adatto a scenari enterprise, sono molteplici e differenti rispetto a quelle supportate da REST pertanto, sebbene possano risultare due paradigmi convergenti, rispondono ad esigenze e scenari profondamente diversi.

Nella selezione dei due diversi approcci, è utile distinguare alcune caratteristiche peculiari di SOAP:

• Facilità di fruizione e disponibilità di strumenti. (pensiamo a "add web/service reference" di Visual Studio);
• Forte tipizzazione dei dati, aderenti ad uno schema;
• Rappresentazione dei dati in formato XML, all'interno di un "soap-envelope" (header + body);
• Invocazione mediante POST (su HTTP);
• Supporto della sessione, routing e transazioni;
• Trasporto multiprotocollo (tipicamente HTTP, ma disponibile anche su SMTP, TCP, e via discorrendo);

Di seguito invece, alcune caratteristiche tipiche di REST:

• Formato non fortemente tipizzato dei dati;
• Markup leggero, semplificato e "leggibile";
• Rappresentazione dei dati in formati differenti, ma largamente riconosciuti (soprattutto JSON);
• Invocazione mediante i metodi propri di HTTP (GET, POST, PUT, DELETE);
• Possibilità di sfruttare la cache di HTTP per le response;
• Trasporto solo su HTTP o HTTPS;
• Portabilità, consumo da qualsiasi piattaforma

Il trend attuale sembrerebbe premiare l'adozione di un'architettura REST, nell'ambito dell'implementazione di servizi data-oriented: pensiamo al diffondersi le applicazioni web sempre più sbilanciate lato client (SPA), ai dispositivi mobile praticamente sempre connessi, cui debbono convergere gli stessi dati delle controparti desktop senza penalizzare la disponibilità limitata di banda.

Il pilastro dell'architetura REST è sintetizzato dall'acronimo HATEOAS (Hypermedia as the engine of application state), ovvero porre al centro dell'architettura le risorse, esplorabili secondo precise convenzioni e rappresentabili in diversi formati (media types). Con questo paradigma il client può consumare il servizio senza conoscere a priori, e dettagliatamente, il funzionamento e la struttura dello stesso, né tantomeno il formato dei diversi tipi di dati disponibili. Questo approccio è ritenuto future-proof, ossia in grado di anticipare o di adattarsi facilmente a future necessità. REST aderisce nativamente a un protocollo ormai consolidato (HTTP), che ad oggi non ha eguali in termini di diffusione e penetrazione: è la corsia preferenziale per raggiungere e supportare un vasto insieme di tipologie di client, inclusi i browser e i device mobile.