L’approccio REST di

Microsoft

Mi presento

Gaetano Paterno’Mail:

tanopaterno@gmail.com

Facebook: gaetano.paterno.77

Web Service - Le origini

L’utilizzo del Web come piattaforma di programmazione è un’idea

che si è diffusa intorno al 2000 con l’introduzione dei Web service.

L’approccio è sostanzialmente basato su una definizione di funzione

richiamabile via Web.

I Web service consentono di far interagire due applicazioni

indipendentemente dal sistema operativo su cui girano e dal

linguaggio di programmazione utilizzato.

Tecnicamente il meccanismo di interazione è basato sul protocollo

SOAP, su un insieme di regole che definiscono la struttura

dei messaggi scambiati dalle applicazioni e tutta una serie

di accorgimenti per garantire sicurezza, affidabilità,

corretta gestione degli eventi, ecc.

Web Service - REST

Un approccio alternativo ai Web service basati su SOAP, che è stato

proposto negli stessi anni ma è stato riscoperto soltanto negli ultimi

tempi, è l’approccio noto come REST (Representational State Transfer).

In sintesi, nella visione RESTful un Web service non definisce una funzione

richiamabile da remoto ma mette a disposizone delle risorse su cui è

possibile effettuare le classiche operazioni CRUD sfruttando i metodi del

protocollo HTTP.

L’approccio REST di Microsoft

Con ASP.NET Web API, Microsoft ha deciso di realizzare i Web service

RESTful basandoli sul meccanismo di routing di MVC.

ASP.NET Web API è parte integrante di ASP.NET MVC 4.

Il modello architetturale MVC (Model-View-Controller) suddivide

un'applicazione in tre componenti principali:

- il modello,

- la visualizzazione

- e il controller.

Il pattern MVC

Il pattern MVC include i seguenti componenti:

- Modelli. Gli oggetti modello rappresentano le parti dell'applicazione

che implementano la logica per il dominio dei dati dell'applicazione.

Spesso gli oggetti modello recuperano e archiviano lo stato del modello

in un database.

- Visualizzazioni. Le visualizzazioni sono i componenti che consentono

di visualizzare l'interfaccia utente dell'applicazione. Questa interfaccia

utente viene in genere creata in base ai dati del modello.

- Controller. I controller sono i componenti che gestiscono l'interazione

dell'utente, utilizzano il modello e selezionano infine una visualizzazione

per il rendering dell'interfaccia utente.

In un'applicazione MVC la visualizzazione consente solo di

visualizzare le informazioni. Il controller svolge il ruolo di gestore

e risponde all'input e all'interazione dell'utente

Chiamare la Web API

Pubblicata, ad esempio, la nostra web api è sulla macchina di sviluppo

alla porta 1039, potremmo aprire un browser e farlo puntare

all’indirizzo http://localhost:1039/api/items/API per ottenere un risultato

analogo al seguente:

Chiamare la Web API

Accedere ad una Web API tramite un browser non è però la situazione

standard. Un Web service normalmente è pensato per essere utilizzato

via codice. Vediamo quindi come sfruttare la nostra API tramite

JavaScript. Ad esempio utilizzeremo jQuery (ma è possibile utilizzare una

qualsiasi libreria) per interrogare via Ajax la Web API.

$.getJSON("api/items/" + id,

function (data) {

var str = '<p><b>' + data.term + '</b><br/>' + data.definition + '</p>';

$('#divDefinizioni').html(str);

}).fail(

function (jqXHR, textStatus, err) {

$('#divDefinizioni').html('Error: ' + err);

});

Chiamare la Web API

Nella descrizione generale del funzionamento interno del framework

abbiamo detto che una risorsa viene individuata tramite un URI e che,

in base al metodo HTTP ed agli eventuali parametri, viene individuato

il metodo del relativo controller da invocare.

Ma come fa il framework ad individuare la risorsa corretta?

Come fa a sapere qual è il controller associato e che un suo

determinato metodo corrisponde al metodo HTTP specificato dal client?

Lo schema dell’URI

Se andiamo a curiosare nel Global.asax della nostra applicazione

scopriremo che è stata definita una route come la seguente:

/api/{controller}/{id}

La route definisce uno schema di URL con {controller} e {id} come

segnaposto per il controller della risorsa e l’eventuale identificatore.

Alla ricezione di una richiesta HTTP, il sistema analizzando l’URL andrà

alla ricerca di un controller per la risorsa specificata. L’individuazione

del controller viene effettuata concatenando al nome indicato al posto

di {controller} con la parola chiave controller.

Quindi, facendo riferimento al nostro esempio, per gestire

l’URL /api/items/API, il sistema cercherà un controller con

nome ItemsController.

Gestione CRUD delle risorse

Finora abbiamo esaminato l’accesso in lettura ad una singola risorsa o

ad un elenco di risorse del nostro glossario.

Seguendo i principi dell’architettura REST, l’accesso in lettura alle risorse

è associato al metodo HTTP GET.

Spesso però è necessario prevedere un accesso anche in scrittura per

poter creare, modificare o eliminare risorse.

Si tratta in sostanza di implementare le classiche operazioni CRUD:

Create, Read, Update, Delete.

L’approccio REST prevede che queste quattro operazioni corrispondano

rispettivamente ai quattro metodi principali del protocollo HTTP.

Gestione CRUD delle risorse

Per approfondimenti

http://www.asp.net/web-api/overview/getting-started-with-aspnet-

web-api/tutorial-your-first-web-api

https://msdn.microsoft.com/it-it/library/dd381412(v=vs.108).aspx

DEMO