Questo Guest Post è stato scritto da Ugo Lattanzi, MVP ASP.NET

Introduzione

Con la nuova versione (in beta) di ASP.NET MVC 4, Microsoft ha rilasciato un’interessante novità chiamata Web API, che offre l’opportunità di esporre dei servizi web senza l’utilizzo di WCF o SOAP ma semplicemente basandosi su chiamate REST.

Con il diffondersi dei social network questo approccio ha preso il largo: le API di Twitter e Facebook funzionano in questo modo, ed oggi è possibile implementare qualcosa del genere riducendo drasticamente la pipeline della richiesta web.

In realtà questo framework era già presente nel mondo .NET, veniva hostato tramite Windows Comunication Foundation, e prendeva il nome di WCF Web API.

Purtroppo questo tipo di approccio risultava un po’ macchinoso, ed in ogni caso richiedeva la conoscenza di WCF (attributi, configurazione etc); per questo motivo Microsoft ha deciso di spostare questo framework su ASP.NET.

Installazione

Se avete installato Visual Studio 2011 Beta non dovete far nulla, al suo interno è infatti contenuto ASP.NET MVC 4 e di riflesso il Web API. Al contrario potete scaricare il framework tramite il Web Platform Installer oppure la versione standalone da questo link.

Utilizzo

Essendo il Web API una parte di ASPNET MVC, è necessario selezionare quest’ultimo come template di progetto da Visual Studio e poi da lì scegliere Web API, come mostrato dallo screenshot seguente:

image

Una volta premuto “OK”, Visual Studio provvederà a creare la struttura di folder necessaria alla nostra applicazione e, come potrete vedere dal Solution Explorer, questa non si discosta molto da quella creata tipicamente per un’applicazione ASPNET MVC.

La prima cosa da notare è la presenza di un controller chiamato ValuesController che, a differenza dei comuni controller MVC, eredita da una classe chiamata ApiController.

Al suo interno troviamo un set di Action (GET, POST, PUT e DELETE) che, a differenza delle action MVC, non sono mappate in base al nome della Action, ma in base alla loro azione.
Prima di addentrarci di più nel codice è necessario che sia ben chiaro questo concetto, quindi andiamo a vedere come le API vengono mappate all’interno del routing:

image

Con la WebAPI è stato introdotto un nuovo metodo per la classe RouteCollection, che ci consente di registrare le “rotte” - passatemi il termine - per i nostri ApiController.
A differenza del classico MapRoute potete notare l’assenza della action all’interno del routeTemplate; questo avviene perché il nome delle action invocate segue una rigida naming convention, che segue i metodi HTTP GET/POST/PUT/DELETE.

Questo vuol dire che, per un controller che dovrà gestire gli utenti, avremo un set di action come il seguente:

Action

http Method

Relative Uri

Recupera la lista di utenti

Get

Api/User/

Recupera uno specifico utente

Get(int id)

Api/User/Id/

Crea un nuovo utente

Post(User user)

Api/User

Aggiorna un utente

Put

Api/User/Id/

Cancella un utente

Delete

Api/User/Id/

Tradotto in codice, l’implementazione dello UserController potrebbe essere più o meno così:

image

A questo punto non vi resta che testare l’applicazione e, solo per le chiamate in GET, vi basterà digitare l’url direttamente nella finestra del browser http://localhost:1386/api/user/1 per verificare la risposta:

image