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.
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