3 pagine in totale: <<Indietro 1 [2] 3 Avanti >>
REST vs Web Services
Generalmente la maggior parte di questi servizi sono forniti attraverso un'implementazione REST, che consiste nell'utilizzare HTTP come rappresentazione di un protocollo, grazie ai suoi metodi ed alla possibilità di inviare comandi attraverso la composizione di URL ad hoc.
Il servizio più utilizzato a sfruttare l'alternativa SOAP, cioè un approccio basato su Web Services (intenso come servizi erogati attraverso web, con un contratto ben definito) è certamente quello dedicato alla ricerca (Live Search). D'altro canto quello più utilizzato con un'interfaccia REST è VirtualEarth, che è generalmente confuso con il sito Live Maps, che invece resta una implementazione delle API. Entrambi questi servizi saranno approfonditi in maniera specifica nel corso di prossimi articoli, ma restano due tra le punte di diamante dei servizi offerti nel bouquet di Windows Live.
Quello che invece è senza dubbio utile sottolineare è la differenza di approccio che questi due sistemi offrono. Da un lato c'è la correttezza formale dell'approccio basato su servizi, che prevede un contratto che indica in maniera chiara e precisa quali tipi di richieste sono consentite, con quali parametri e con quale tipologia di risultato, basandosi su standard tutto sommato diffusi e consolidati, come SOAP e le specifiche WS-*. In questi scenari non è necessario creare un meccanismo di parsing della risposta (nè di generazione della richiesta) poichè spesso le action del servizio prevedono dei percorsi implementativi da cui è difficile discostarsi, aiutando come già detto a seguire una correttezza formale decisa da chi ha impostato il servizio. Questo garantisce, banalmente, meno possibilità di interpretazioni e più sicurezza, grazie all'uso di standard già noti ed evitandone di inventarsene di nuovi.
D'altra parte l'approccio REST-ful ha dalla sua l'estrema facilità di implementazione. Molte delle API sono fornite attraverso Javascript, con possibilità minima di personalizzazione, o con chiamate ad URL che producono un certo output come risultato, con le problematiche legate a sicurezza e gestione del parsing del risultato. Tuttavia, nonostante REST parta in apparente svantaggio, è la scelta preferita quando si implementa questo genere di servizi, semplicemente perchè gli sviluppatori che andranno a sfruttarli sono più liberi di costruirci intorno quello di cui hanno bisogno, con meno rigidità e più semplicità.
A meno che non mettiate in piedi un sistema di social networking o un qualche tipo di API, vi troverete con molta probabilità a subire queste decisioni, più che a dover decidere cosa è meglio per il vostro sistema. Tuttavia la comprensione dei motivi che spingono alla scelta di uno o dell'altro in certi contesti può rappresentare la differenza tra un uso semplicistico ed uno consapevole del servizio.
L'offerta di Windows Live Services
Attualmente Windows Live si compone di tutta una serie di servizi che consentono di entrare in contatto ed integrarsi con alcuni tra i servizi più famosi, come Windows Live Messenger, Live Search, Live ID, Live Spaces.
Se avete almeno una volta dato un'occhiata a quest'ultimo, avresti sicuramente notato che all'interno degli Space di un singolo contatto c'è una scheda dettagliata che mostra alcune informazioni aggiuntive, prese dal profilo stesso:
Nel caso di Live Spaces, Microsoft tutto sommato gioca in casa, eppure essendo questi sistemi sviluppati da team differenti, c'è la necessità che condividano informazioni tra di loro. Nel caso specifico vengono integrate informazioni dal profilo personale e da Messenger, in un solo risultato.
Tutto questo è possibile perchè attualmente l'offerta dei servizi si sviluppa seguendo questa lista:
- Windows Live Contacts API - Beta 1.0
- Windows Live Spaces Photo API - Alpha 1.0
- Windows Live Messenger IM Control
- Windows Live Presence API
- Virtual Earth Map Control SDK
- Microsoft MapPoint Web Service
- Live Search API
- Windows Live ID
- Windows Live Data SDK - Alpha 1.0
- Microsoft Silverlight Streaming SDK
- Microsoft adCenter API
- Windows Live Alerts SDK
- Windows Live Custom Domains SDK
- Windows Live Expo API
- Windows Live Messenger Activity SDK
- Windows Live Writer SDK
Tutti i servizi sono disponibili attraverso un SDK o delle API, a seconda che sia necessario integrarli usando codice che ne sfrutti le funzionalità o chiamate alle API, pubbliche. In molti casi è necessario procurarsi una chiave, che nella maggior parte dei servizi è gratuita. In tutti i casi sul sito ufficiale dedicato agli sviluppatori si possono approfondire tutte le tematiche relative a ciascun servizio, con particolare riferimento alla documentazione e ad esempi già pronti. Alcuni dei servizi prevedono una licenza commerciale o particolari restrizioni, ma in tutti i casi nel sito dedicato allo sviluppo questi limiti sono sempre ben evidenziati.
3 pagine in totale: <<Indietro 1 [2] 3 Avanti >>
Contenuti dell'articolo
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Stampa 
Download 
