I primi passi con PhoneGap: accesso ai dati tramite Web API di MVC 4

Print Content | More

Come promesso la volta scorsa, avevo intenzione di scrivere un post con lo scopo di mostrare come raggiungere lo stesso obiettivo dell’altra volta (consumare un servizio REST sfruttando jQuery) utilizzando però un servizio realizzato da noi invece di uno già esistente (ricordate Bacom Ipsum)?

Nel momento in cui ho scritto quel post erano due le strade che stavo valutando utilizzando le tecnologie Microsoft:  WCF Data Services oppure ASP.NET MVC. La prima è la soluzione più adatta, dato che WCF è una tecnologia che nasce espressamente per gestire servizi, ovvero tutte quelle applicazioni che tipicamente non richiedono un’interazione umana ma si limitano a esporre dati e/o operazioni che vengono poi consumate da altre applicazioni.

I servizi WCF non sono però così semplici da realizzare e, anche utilizzando la variante Data Services con il supporto al protocollo OData, non è offerto il supporto nativo a JSON come formato in cui esporre i dati (ma bisogna ricorrere ad alcuni espedienti, come quelli spiegati in questo post); supporto che invece è fornito da ASP.NET MVC, grazie alla possibilità di restituire una JsonResult come risultato di una Action definita in un controller.

ASP.NET MVC però non sempre è la tecnologia migliore, dato che il suo scopo, al contrario di WCF, è quello di realizzare applicazioni che sappiano rispondere all’interazione umana: siti, form, intranet, ecc. Se abbiamo già un sito realizzato con questa tecnologia e dobbiamo esporre alcune informazioni tramite servizi, allora può essere una buona soluzione quella di appoggiarsi direttamente a ASP.NET MVC e “ospitarli” in un controller. Se però dobbiamo mettere in piedi un sito basato su ASP.NET MVC solamente per esporre questi servizi, allora il gioco potrebbe non valere la candela.

Settimana scorsa è stata presentata ufficialmente la prima beta di ASP.NET MVC 4, che tra le altre cose ha introdotto proprio una novità che fa al caso nostro: le Web API. Tale tecnologia era conosciuta come WCF Web API e si trattava di un progetto open source ospitato su Codeplex, che ora è stata integrata all’interno di ASP.NET MVC e ha preso il nome ufficiale di ASP.NET Web API.

Questa tecnologia cerca di coniugare, in maniera più semplice, il meglio di entrambi i mondi: permette di realizzare servizi, usando però le stesse feature di ASP.NET MVC (funzionalità definite all’interno di un controller, routing, supporto a JSON, ecc.).

Quale miglior occasione per sperimentare con questa nuova tecnologia per realizzare un servizio da far consumare alla nostra applicazione Windows Phone realizzata con PhoneGap?

Cosa ci serve?

Per poter utilizzare Web API è necessario installare la beta di MVC 4, tramite la Web Platform Installer, la piattaforma di Microsoft che semplifica l’installazione di tool e prodotti legati al mondo web. Collegatevi perciò alla pagina http://www.asp.net/mvc/mvc4, cliccate sul link Install ASP.NET MVC 4 Beta e seguite le istruzioni.

Una volta completata l’operazione, dovreste trovare in Visual Studio un nuovo template nella sezione Web, chiamato ASP.NET MVC 4 Web Application. E’ quello che andremo ad utilizzare per realizzare il nostro servizio.

La nostra prima applicazione Web API

Dopo aver scelto di creare un nuovo progetto di tipo ASP.NET MVC 4, noteremo subito una differenza con MVC 3: i template a disposizione sono molto più numerosi. Tra questi, ci sarà anche quello che fa al caso nostro: Web API.

SNAGHTML47c9c36

Selezioniamolo e diamo OK e verrà creato un progetto con la stessa identica struttura di un sito ASP.NET MVC: si tratta infatti di un progetto ibrido, che ospita sia un sito web con un template di default e alcune pagine fittizie, sia le Web Api. Se apriamo infatti la cartella Controllers, troveremo due classi già pronte: HomeController è un controller “standard”, che eredita dalla classe Controller e funge da controller per la vista web; ValuesController è invece il controller utilizzato per il servizio ed eredita dalla classe ApiController.

Se guardate il contenuto di questa classe noterete subito una prima differenza rispetto ai controller standard di MVC: le varie funzioni definite al suo interno non restituiscono una ActionResult, ma void o un tipo specifico (ad esempio, string), a seconda della funzione.

Questo perchè i servizi Web API sono servizi REST e, sfruttando il protocollo HTTP, rispondono semplicemente ai comandi resi disponibili da tale protocollo: GET, POST, PUT e DELETE. Le WebAPI sfruttano perciò una convenzione tale per cui è sufficiente che i metodi abbiano i nomi dei comandi perchè vengano invocati in seguito ad una richiesta HTTP con quel comando.

Le Web API sfruttano anche le stesse convenzioni di ASP.NET MVC per quanto riguarda il routing: di default, le API vengono esposte all’URL /api/nomedelcontroller, dove il nome del controller è il nome della classe esclusa la parola Controller (nel controller di default ValuesController, l’URL ad esempio è /api/values).

Le regole del routing, così come per i controller tradizionali che servono le pagine web, sono definite nel file global.asax.cs del progetto: è qui che dobbiamo agire, se, ad esempio, vogliamo cambiare la prima parte dell’URL (/api) oppure definire delle regole di routing più complesse.

Creiamo il nostro controller

Invece di utilizzare il controller di default ValuesController, andremo a crearne uno personalizzato: facciamo clic con il tasto destro sulla cartella Controllers, diamo un nome al controller (nell’esempio che seguirà l’ho chiamato ComicsController, dato che restituirà una serie di nomi di personaggi dei fumetti) e selezioniamo come template API Controller with empty read / write actions.

SNAGHTML4d2179e

Avremo a disposizione un controller con la stessa struttura di quello che abbiamo visto in precedenza: la differenza è che questa volta i servizi verranno esposti tramite l’URL /api/comics.

Il controller che andremo a realizzare è semplicissimo: creeremo un array di stringhe contenente un elenco di personaggi dei fumetti, dopodichè definiremo una funzione Get generica (che restituisca l’intera lista), e una funzione Get specifica che, accettando un parametro in ingresso, permette di ritornare un elemento specifico della lista.

public class ComicsController : ApiController
{
   private string[] heroes = new string[] {"Iron Man", "Wolverine", "Hulk", "Thor", "Captain America"};


   // GET /api/comics
   public IEnumerable<string> Get()
   {
       return heroes;
   }

   // GET /api/comics/5
   public string Get(int id)
   {
       return heroes[id];
   }
}

Testare il funzionamento è molto semplice: lanciamo il debug del nostro progetto (magari avendo preventivamente selezionato di ospitare il sito su IIS Express tramite l’apposita opzione disponibile quando si fa clic con il tasto destro sul progetto in Solution Explorer); verrà caricato di default il sito “fittizio” generato dal template. Ci basta ora inserire l’URL del nostro servizio, come definito nel routing, per vedere il risultato (ad esempio, http://localhost:7392/api/comics, dove 7392 è la porta assegnata da IIS Express alla nostra applicazione).

SNAGHTML4ef61b8

Aggiungendo l’identificativo all’URL dopo lo /, ecco che verrà restituito uno specifico elemento della lista:

SNAGHTML4fcdaaf

L’applicazione Windows Phone con PhoneGap

Dal punto di vista dell’applicazione Windows Phone realizzata con PhoneGap nulla cambia rispetto all’esempio del post precedente, se non l’indirizzo a cui far puntare la chiamate del metodo getJSON:

$("#btnCall").click(function () {
    $.support.cors = true;
    $.getJSON("http://localhost:7392/api/comics/", function (data) {
        $.each(data, function (index, element) {
            $("#result").append(element + "<br />");
        });
    });
});

Il risultato sarà il medesimo della volta scorsa, ovvero gli elementi contenuti all’interno della lista verranno mostrati a video:

image

Where in the world is JSON?

Se siete state attenti, avrete notato qualcosa di anomalo: quando avete chiamato il servizio appena creato con il browser, i dati vi sono stati restituiti nel formato XML. Eppure il metodo getJSON di jQuery è stato in grado di elaborare i dati e mostrarli a schermo: questo è stato possibile grazie ad una delle funzionalità più interessanti delle Web API, ovvero la possibilità per i servizi di restituire in automatico dati XML o JSON a seconda dell’header della richiesta HTTP. Volendo, è possibile inoltre creare dei formatter custom per restituire i dati in altri formati.

Possiamo avere una prova di questo meccanismo utilizzando un tool come Fiddler, che ci permette di intercettare il traffico di rete: qui sotto potete vedere due screenshot, il primo relativo alla chiamata effettuata tramite il browser e il secondo a quella fatta tramite jQuery e l’applicazione Windows Phone.

image

image

Come potete vedere, in base al valore dell’header Accept della chiamata HTTP il nostro servizio è stato in grado di restituire i dati nel formato richiesto.

In conclusione

Abbiamo concluso una panoramica molto semplice su Windows Phone, PhoneGap e accesso ai dati. Magari in futuro ritorneremo sull’argomento, parlando più approfonditamente dell’integrazione tra PhoneGap e le API native di Windows Phone. Come sempre, di seguito trovate il link per scaricare il codice sorgente dell’applicazione basata su Web API che abbiamo realizzato (per quanto riguarda quella Windows Phone potete riutilizzare la stessa del post precedente).


Windows Phone , PhoneGap , Microsoft , MVC , Web API

0 comments

Related Post


(will not be published)
(es: http://www.mysite.com)


  1. #1 da http://www.qmatteoq.com/blog/post/qualche-articolo-interessante-sul-blog-msdn-sdk-7.1.1-e-web-api

    www.qmatteoq.com - Qualche articolo interessante sul blog MSDN: SDK 7.1.1 e Web API