Pour ce dernier jour, seulement 2 sessions au programme : "Live Mesg, Virtual Earth, Search & APIs", et un sujet qui m'intéresse particulièrement : "Tour d'horizon REST en environnement hétérogène", tendance très Web 2.0, pas trop tôt dirons-nous.
Live Mesh, Virtual Earth, Search : API
Séance présentée par Pierre Couzy (Microsoft) - Davy Frontigny (Winwise).
Les services s'articulent selon 2 axes : transversaux : Live Mesh, Virtual Earth, Live Search, Silverlight streaming, utilisateurs : Live Spaces, Live ID
Live Search API 2.0 : objectif : utiliser le moteur de Live Search dans ses propres applications avec plusieurs sources de recherche : Web, Images, News, InstantAnswer (Encarta on line)
Pour le développement, cela nécessite une clé AppID, fournie sur le site http://search.live.com/developers, qui vous permettra également de gérer vos multiples clés, ou d'avoir des ressources de type SDK ou la documentation des APIs.
Plusieurs protocoles disponibles pour tous :
- REST bien entendu avec plusieurs formats de retour : JSON (l'URL aura la forme http://api.search.live.net/json.aspx?<Params>). Remarque : JSON est mieux actuellement car le traitement XML reste très lent dans le navigateur, JSON est sans doute voué à disparaitre à terme; XML (URL du type: http://api.search.live.net/xml.aspx?<Params>), et enfin RSS (URL : http://api.search.live.net/rss.aspx?<Params>).
- et SOAP
Les services transverses
- Live Search : besoin d'un AppID pour l'utilisation de l'API, interrogation directement via l'URL http://api.search.live?net/xml.aspx?Appid=XXXX&sources=Web&Query=querywords
- Virtual Earth : API javascript et contrôle disponibles : vue carte, satellite, 3D - résolution d'adresses et de trajets - insertion de Pushpin (points d'intérêts sur la carte). Nouveautés : contrôle JS : localisation (en 5 langues), regroupement de pushin, méta données des images, import de modèles 3D, Web services : service d'imagerie, de recherche, de GeoCode
Le SDK est directement testable à l'adresse http://dev.live.com/virtualearth/sdk, ce qui vous permettra d'obtenir des bouts de code directement utilisables. Un bel outil très pratique pour se faire la main sur le SDK.
La démonstration, orientée sur les places Velib' disponibles est accessible sur ce site.
Les services à l'utilisateur
- Silverlight streaming : espace de 10 Go http://silverlight.live.com, manipulable directement via une API, REST/WebDav
- Live Spaces : espace provisionné pour des contenus structurés : Photos, Blog, Fichiers (SkyDrive), Contacts et amis, Listes, Evènements accessibles en RSS ou directement par les pages
Voir ces application prêtes à l'emploi, l'application Contoso university a été prise comme exemple durant la session.
Démo on the cloud : Communities (exemple d'argument /default.htm?cn=villedeBbordeaux) héberge une application SL.
- Gestion des utilisateurs : l'authentification s'effectue via LiveID, le site utilisateur ne connait pas l'utilisateur - l'utilisateur contrôle son identification sur les différents sites, et peut révoquer à tout moment une autorisation. L'utilisateur expose les données qu'il souhaite aux sites sélectionnés pendant une durée donnée (NDR : cela ne vous fait pas penser à OpenID vous ?)
- Live Identity Services : plusieurs SDK disponibles, dans plusieurs langages.
- Live Mesh, vous donne droits à cet ensemble de fonctionnalités : stockage de 5 Go, synchronisation des fichiers entre devices (en ligne, local), partage de répertoires avec d'autres utilisateurs, prise de contrôle de PC à distance (NDR : cela fonctionne très bien, passe le firewall, j'ai pu prendre le contrôle à partir de chez moi, de ma station de travail au bureau, avec un plein écran possible), réplicat d'une zone en ligne sur un répertoire local (synchronisation), à l'aide du.clic droit sur un répertoire local pour inviter d'autres personnes, selon des droits spécifiques (contributeur, lecteur, propriétaire)
Un exemple d'utilisation de Mesh, avec partage et prise de contrôle à distance :
Prochaine version : Mesh vNext (CTP) : disponible uniquement sur invitation, apporte une API pour le développement (pour l'intégration à des applications existantes).
Durant la démonstration, j'ai pu voir la possibilité de créer des applications SL en local (ie : plus besoin du navigateur), mystère...
Tour d'horizon REST en environnement hétérogène
Speakers : Thierry Boileau (Noelios Techno., framework Java RESTlet) - Stève Sfartz (MS - architecte)
En 1993, le web = contenu, en 2008, le web = plateforme. Nous sommes entrés dans l'ère de l' orientée ressources : applications Ajax, SL, services en ligne, Mashups
WOA : Web Oriented Architecture : REST, repose sur les standards W3C (URI, Media Types / MIME, HTTP 1.1, XML/XHTML/JSON)
Contraintes REST
2000 : thèse de Roy Fielding (chapitre n° 5) :
Client Serveur, distribution via HTTP Communication sans état Cache possible (ETags, GET conditionnel) Interface uniforme (GET, PUT, POST, DELETE, ...) Identification des ressources par les URIs Code à la demande : Javascript ou Sillverlight Système en couches
Les ressources sont identifiées par une URI, selon les principes du GET, POST, PUT, DELETE, basés sur HTTP - 2 verbes supplémentaires sont disponibles : HEAD (ne retourne que les méta-données), OPTIONS (obtient des information sur les ressources, avec une description plus riche au format WADL)
Méthodes sûres (sans effet de bord possible : en GET) et idempotentes (méthodes qu'on peut répéter N fois en ayant le même résultat : PUT, DELETE)
Résumé : REST est un style d'architecture et non une spécification, repose sur les standards du Web, celui-ci est vu comme un graphe de ressources liées et identifiées par des URIs, avec un ensemble d'opérations sur ces dernières.
Concevoir une API REST :
Identifier les ressources de votre applications Conception des URI Choix des méthodes Conception des représentations : format, schémas, exemples Définition des codes retours HTTP
Conception des URIs : collection, ressource (par exemple /students), paramètres de présentation : orderby, pagination (/students?top=10&skip=30), filtre (filter=sibstring(chp,'toto'))
Codes de statut / retour HTTP : 1xx : info, 2xx : succès, 3xx : redirection (301 moved permanently), 4xx erreurs client, 5xx : server error (voir ce RFC)
Nous pouvons avoir plusieurs approches REST, selon une échelle allant des puristes jusqu'à l'opposé, les pragmatiques :
- Puristes : URIs bien construites, commandes HTTP GET, PUT, DELETE, POST, exploitation des représentations (retour en XML, JSON, autre)
- Pragmatiques : pas de règles autour des URIs, command HTTP GET (consultation), POST : fourre-tout, sces Ajax, POX
REST : implémentations .NET
Comment effectuer des appels POST / PUT vers le service REST ? soit en utilisant l'irremplaçable Fiddler, ou via des appels WebRequest / HttpRequest programmés dans une application (NDR : voir cet exemple de ce type d'appel).
WCF à l'état brut en 3 étapes : contrat de service sous forme d'interface (astuce : au-dessus du contrat : assembly: ContractNamespace("",ClrNamespace="DataGridRESTClient.Web") pour retirer les ''namespaces'' XML), __implémentation__ du contrat ([AspNetCompatibility), configuration de service.
Implémentations par défaut des différents scénarios REST : WCF REST Starter kit (templates dans les projets Web) : WCF Atom Feed Service, WCF REST Collection service, ...
ADO.Net Data Services
Framework orienté Ressources Exposition des données existantes Interface graphique pour mapper le modèle relationnel vers le modèle Web (REST) CSDL : http://dummy.net/service.svc/$metadata : schéma des méta-données qui sont exposées - possibilité de requêtes Linq directement sur le service (from c in service.Customer ...)
Synthèse : REST s'impose pour des intégrations légères et performantes avec le web, les technos. interopèrent par conception naturellement
Sécurité : ASP.NET provider (membership, ...), contexte IIS passé à WCF - Azure : header Authorization
Conclusion de ces Techdays 2009
Concernant l'évènement, cette année, j'ai été particulièrement ravi d'y participer. Est-ce parce que j'ai choisi un peu mieux mes sessions, ou que l'organisation était peut-être un peu mieux gérée que les années précédentes, en tout cas, j'y reviendrai.
Il n'y a pas si longtemps, je pensais sincèrement que MS avait pris énormément de retard concernant les services en ligne, face à Google, ou dans une moindre mesure Amazon.
Ces 3 jours m'ont prouvé le contraire, la puissance de réaction de Microsoft a encore frappé : l'ensemble des services Azure / Live, avec une adoption d'APIs au format REST (sans compter WCF 3.5) sont en bonne voie et m'ont particulièrement plus et donnent réellement de s'y mettre. Les SDK sont d’ores et déjà là pour nous faire trépigner les doigts d'impatience.
Associer des APIs à des interfaces, en Ajax (Javascript jQuery ou Ajax 4.0, JSON, ...), mais surtout en Silverlight trouvent tout leur sens et leur utilité dans un monde toujours plus interopérable et dans une mouvance toute Web 2.0.
On remerciera également François Cointe, dessinateur, pour ces planches de dessin.
Y'a plus qu'à les enfants.