Nello scorso post ho parlato solo di uno degli argomenti di cui ho parlato nel workshop UGIdotNET. La maggior parte del tempo l'ho dedicata alle WCF WebAPI, tutt'ora in CTP, che faranno parte del nuovo corso di WCF e che sono disponibili su http://wcf.codeplex.com.
WCF WebAPI siede sopra la potente infrastruttura dl WCF che conosciamo ma rivoluziona totalmente il suo uso tanto che non sono più necessari file di configurazione sostituiti da una piacevole Fluent-API. Ad ogni modo è sempre possibile intervenire con custom behavior.
Perché le WebAPI sono importanti? Per rispondere a questa domanda ci vuole una prospettiva architetturale per capire dove si collocano le WebAPI rispetto alle altre tecnologie presenti oggi come SOAP (WCF classico), RIA, Data Services, Rest Toolkit e Asp.net MVC (per la parte postback json).
La risposta lunga sta nel video della sessione che è disponibile qui.
La versione breve è che la necessità di interoperabilità tra device di tipo eterogeneo ha spinto il mondo informatico ad andare verso protocolli più semplici di SOAP, standard e diffusi. Il principe di tutti questi è certamente HTTP, già utilizzato dalle tecnologie precedenti ma in modo differente rispetto alle WebAPI.
Il principio da cui partono le WebAPI è di utilizzare Http non solo per trasportare delle informazioni ma adatto a descrivere un vero e proprio ecosistema che permette di interoperare. Le specifiche Http infatti forniscono strumenti avanzati per descrivere un dialogo con regole molto precise. Il verb GET è adatto a recuperare informazioni e le specifiche dicono chiaramente che nessuna modifica lato server debba essere fatta a seguito di una GET. I verb PUT e DELETE sono verb di tipo per eseguire delle modifiche idempotenti, vale a dire che la loro esecuzione dopo la prima volta non cambia il risultato. E ancora che ad ogni richiesta eseguita con il verb POST, analogo di una Insert su un db, corrisponderà un cambiamento. Ecco spiegato perché SOAP su HTTP usa solo il verb POST.
Http fornisce molto altro come il supporto al caching e sul lato ITPro esistono già dozzine di apparati e software che conoscono Http e permettono di trattarlo come tale, basti pensare a proxy, firewall, content-intspection etc.
Questo è il mondo di REST che non è un modo per avere Uri belli a vedersi ma che sfrutta pienamente Http e ci permette di avere pieno controllo sulle Request e sulle Response ricevute/effettuate dal server. Ecco perché WebAPI rimpiazza totalmente il vecchio REST toolkit che andrà quindi in obsolescenza.
I 'goodies' di questa libreria sono tantissimi e tra questi c'è il superlativo concetto di Formatter. Diciamo di avere un servizio che eroga un Contact. Questo è descritto in una entity e le WebAPI ci permettono di mantenere totalmente separata l'entità da tutte le sue possibili rappresentazioni (serializzazioni se preferite). Il Contact potrà essere così serializzato in formato XML, Json ma anche una vCard, un immagine png o anche uno stream di dati oData.
Quello che colpisce non è tanto la trasformazione in formati differenti ma il modo semplice, e rispettoso delle specifiche Http, con cui viene scelto il formato di serializzazione.
L'esempio più lampante è l'header "accept" che è pensato in Http proprio per indicare al server qual'è la rappresentazione preferita per rappresentare la risorsa richiesta.
Grazie a Message Handlers e Operation Handlers la pluggabilità è totale e permette di gestire il flusso di richieste e risposte in modo modulare e ben organizzato.
Ovviamente la libreria ha molte altre sorprese per chi voglia esplorarle tra cui la parte client che ho utilizzato per costruire un tool WPF per eseguire i test che ho fatto durante la mia sessione:
Congratulazioni a Glenn e al team di WCF per lo splendido lavoro fatto. Invito tutti a provare le nuove librerie, consapevoli del fatto che potrebbe ancora esserci attività di refactoring ma personalmente non mi aspetto grossi cambiamenti anche perché si usa il consolidato protocollo HTTP.
Nel prossimo futuro tornerò ad analizzare l'implementazione e l'uso delle librerie. È chiaro che in questo momento, come dicevo in sessione, è bene capire capire se nel proprio business questa libreria possa fornire uno strumento per migliorare l'architettura sul lato servizi.