Téléchargé 56 fois
![Forever frame
1
HTTP/1.1 200 OK
2
1 2 3 <script>eval(“{id:’1’}”)</script>
3
<script>eval(“{id:’2’}”)</script>
Event Event [ . . .]](https://image.slidesharecdn.com/web304-webapisignalr-v1-1-0-public-130416072954-phpapp02/85/Asp-Net-Web-API-SignalR-et-UX-le-futur-46-320.jpg)
![SignalR Code : Hub
var hub = $.connection.Notifier; 1 [HubName(“Notifier”)]
public class MyHub : Hub
{
$.connection.hub.start().done(function () { public void Notify(string message)
$('#btn').on('click',function(){ 2 {
hub.server.notify( Clients.Others.notified(message);
$('#messageInput').val()); }
}) }
3
});
hub.client.notified = function (message) {
alert(message.Content); RouteTable.Routes.MapHubs();
};
Client Server
Partie Cliente](https://image.slidesharecdn.com/web304-webapisignalr-v1-1-0-public-130416072954-phpapp02/85/Asp-Net-Web-API-SignalR-et-UX-le-futur-61-320.jpg)
Téléchargé parMicrosoft
Asp.Net Web.API, SignalR et UX : le futur
Ce document présente les concepts liés à ASP.NET Web API et SignalR, en mettant l'accent sur leur rôle dans le développement d'applications réactives et en temps réel. Il aborde l'évolution des API web, les architectures REST, et les capacités de SignalR pour faciliter la communication bidirectionnelle et le traitement des données en temps réel. Enfin, des informations pratiques sur l'utilisation de ces technologies et des exemples de code sont fournies pour illustrer leur mise en œuvre.
Contenu connexe
![02 - [ASP.NET Core] ASP.NET Core MVC](https://cdn.slidesharecdn.com/ss_thumbnails/02-asp-170124120155-thumbnail.jpg?width=640&height=640&fit=bounds)
![03 - [ASP.NET Core] Services RESTful et SPA](https://cdn.slidesharecdn.com/ss_thumbnails/03restfuletjavascriptservices-170124115925-thumbnail.jpg?width=640&height=640&fit=bounds)
Similaire à Asp.Net Web.API, SignalR et UX : le futur
Asp.Net Web.API, SignalR et UX : le futur
- 1. Asp.Net Web API, SignalR, UX: Futur Thomas Jaskula Rui Carvalho Développeur Développeur Compose IT ArtOfNet @tjaskula @rhwy Code / Développement
- 2. About Talk Work @rhwy @tjaskula ArtOfNet Formations Blog codedistillers.fr En> www.codedistillers.com skill-track.fr Fr > www.rui.fr
- 3. Communautés Prochaines rencontres: 13/02 : Agile.Net beer 21/02 : Alt.Net Frameworks .Net oss 26/02 : Vue d’ensemble du DDD 27/02 : Alt.Net Coding breakfast Paris Software Craftsmanship xx/05 : Web.Net conf Paris ! Community www.meetup.com /ALTNETFR /DDD-Paris /paris-software-craftsmanship /AGILE-NET-FRANCE
- 4. API, REAL TIME& UX
- 5. à propos decette session DISCLAIMER
- 6.
- 7.
- 8.
- 9.
- 10.
- 11. Toute l’information, toutde suite
- 12. Comment répondre àces évolutions?
- 13.
- 14. Mettre en placedes API Standardisées Au coeur de l’application Simples, autonomes
- 15. Communication temps réel Fournir de l’information < 1s Frameworks spécialisés Travailler ses écrans comme de vrais applications
- 16.
- 17. ASP.NET Web Api • Qu’est-ce qu’une API Web ? « Une API Web est une interface programmable d’un système exposé sur HTTP et accessible par des méthodes HTTP standard ». Code / Développement
- 18. ASP.NET Web Api • Origines des API web 8571 ! 10000 07/02/2013 8000 6000 4000 2000 0 2001 2008 2000 2002 2003 2004 2005 2006 2007 2009 2010 2011 2012 2013 *source : http://www.programmableweb.com Code / Développement
- 19. ASP.NET Web Api/ Introduction REST • Origines des API web Usage des protocoles par API 5% 2% REST 24% SOAP JavaScript 69% XML-RPC *source : http://www.programmableweb.com 07/02/2013 Code / Développement
- 20. ASP.NET Web Api • Architectures, protocoles & styles des API Web – RPC API XML-RPC CORBA DCOM WSDL – Message API SOAP POX – Ressource API ATOM REST Code / Développement
- 21. ASP.NET Web Api • Architecture Web – Pensez « Ressources » Représentation XHTML Content-Type : application/xhtml+xml URI Représentation JSON http://api.demo/order/1234 Content-Type : application/json http://api.demo/order/1234.js p Représentation PDF Content-Type : application/pdf Ressource urn:api.demo:order:1234 Représentation TEXT Content-Type : text/plain ftp://demo/order/1234.txt Code / Développement
- 22. ASP.NET Web Api • D’une architecture web vers un style d’architecture… REST = Décrit le web comme une application ressources laquelle les représentations hypermédia liées communiquent en échangent les de ressources. distribuée dans http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm Code / Développement
- 23. ASP.NET Web Api • Contraintes du style architectural REST Vous obtenez ces REST Contrainte Vous n’adhérez pas Bénéfice bénéfices si vous à ça… Et vous n’aurez pas utilisés HTTP Client - Server ça ! - Portabilité UI - Serveur simplifié Si vous ne faites comme protocole depas ça… votre Stateless - - Serveur simplifié Extensibilité application - Fiabilité Optional non-shared caching - - Latence réduite Efficacité Sous-contraintes: - Extensibilité Uniform interface - Visibilité - identification des ressources - Evolution Indépendante - Implémentation découplée - Manipulation via représentations - Messages auto-descriptifs Layered system - - Cache partage Clients simplifiés - Hypermédias - Load balancing et extensibilité Code-on-demand - - Clients simplifiés Extensibilité Code / Développement
- 24. ASP.NET Web Api • Convivialité du Web / Modèle de maturité Hypermédias Niveau 3 HTTP Niveau 2 URI Niveau 1 Niveau 0 Leonard Richardson http://www.crummy.com/writing/speaking/2008-QCon/ Code / Développement
- 25. ASP.NET Web Api • Introduction au Framework • Pourquoi utiliser ASP.NET Web Api ? • ASP.NET Web Api vs. ASP.NET MVC • Et le WCF dans tout ça ? Code / Développement
- 26. ASP.NET Web Api • Introduction au Framework Principales caractéristiques : - Support complet HTTP - Content-negotiation - Tests unitaire - Indépendance de hosting Code / Développement
- 27. ASP.NET Web Api • Hosting – Adaptateurs disponibles (indépendant du Framework) • WebHost (IIS) • SelfHost (Process Windows) – Adaptateurs personnalisés • Azure • In-Memory • OWIN Code / Développement
- 28. ASP.NET Web Api • Adaptateur Azure Service Bus Relay Windows Azure IP Public Service Bus Nom DNS Public Relay API Host Client API NAT Firewall IP Privé Pas de nom DNS Code / Développement
- 29. ASP.NET Web Api • Hypérmedias – Pourquoi construire les applications hypermédias ? – Media types • XML / JSON • XHTML / ATOM • HAL Code / Développement
- 30. ASP.NET Web Api • Résumé – Support technologique – Performances, extensibilité et monté en charge – Faible couplage – Workflow métier Code / Développement
- 32.
- 33. SignalR? Runtime temps réel pour .Net
- 34. SignalR? Framework Client(s) Serveur
- 35. De quoi parle-t-on… LEWEB TEMPS RÉEL?
- 36. Le web tempsréel Push Serveur HTTP Streaming/Comet WebSockets
- 37. L’information tout desuite, oui mais… QUEL EST LE PROBLÈME?
- 38. Un seul canaluniversel ! HTTP
- 39. HTTP n’est Pasadapté Le procole est agé Il n’a jamais été prévu pour ça Prévu pour fournir des documents liés
- 40. Les fondamentaux HTTP Le web est stateless Uniquement Requêtes/Réponses
- 41. HTML5 WebSockets ? Extension de HTTP Supporte les proxies Canaux binaires bi-directionels
- 42. HTML5 WebSockets ? Spécification instable Support Serveur/Navigateur aléatoire Protocole applicatif à écrire!
- 43. Quelles Alternatives aujourd’hui? Short polling Long polling Forever frame
- 44. Short polling Event
- 45. Long polling Event
- 46. Forever frame 1 HTTP/1.1 200 OK 2 1 2 3 <script>eval(“{id:’1’}”)</script> 3 <script>eval(“{id:’2’}”)</script> Event Event [ . . .]
- 47. Que choisir? Aucun n’est particulièrement meilleur Tous Avantages différents en fonction du navigateur
- 48. SignalR ! Il prend en compte toutes ces techniques S’adapte en fonction du navigateur Et du serveur automatiquement Abstraction de programmation
- 49. One to rulethem all SIGNALR
- 50. SignalR Connection suivant le meilleur transport disponible Abstraction simple Modèle de programmation unique
- 51. SignalR Librairie OSS éprouvée Microsoft.AspNet.SignalR (nov 2012) Clients toutes plateforme (JS, .Net, WinRT, iOS,…) Server + WebSockets IIS8
- 52. SignalR Server Fonctionne dans toute application ASP.NET Selft Host Azure Mono
- 53. SignalR API Persistent Connections Hubs
- 54. SignalR Persistent Connections API bas niveau Programmation connection unique IHttpHandler + route Limité aux messages Le protocole doit être défini
- 55. SignalR Hubs API de haut niveau Abstraction au dessus des PersistentConnections Proxies auto générés dynamiques (JS ou .NET) Routes automatiques (/signalr/hubs) Tout types d’échanges, riches
- 56.
- 57. SignalR Performances Très rapide, x18 pour la v1.0 Sur 1 serveur: 250k-500k messages /s 70k connections simultannées
- 58. SignalR Performances les performances dépendent du type de transport Ralentis requêtes html sur le même serveur Attention au traitement (Cpu)
- 59.
- 60. SignalR Code :Install Serveur Web + Clients JS Client .Net Partie Serveur
- 61. SignalR Code :Hub var hub = $.connection.Notifier; 1 [HubName(“Notifier”)] public class MyHub : Hub { $.connection.hub.start().done(function () { public void Notify(string message) $('#btn').on('click',function(){ 2 { hub.server.notify( Clients.Others.notified(message); $('#messageInput').val()); } }) } 3 }); hub.client.notified = function (message) { alert(message.Content); RouteTable.Routes.MapHubs(); }; Client Server Partie Cliente
- 63.
- 64. Résumé • SignalR, framework/Runtimetemps réel .Net web • Modele simple et unifié de programmation avec les Hub • Abstraction du transport • Tous types de clients
- 65.
- 66.
- 67. Keep contact: @RHWY +@TJASKULA
Notes de l'éditeur
- #2 Intro code / dev
- #3 Nous sommes des consultantsindépendants au travers de nossociétésArtOfNet et ComposeIT.Nous fournissonsprincipalement :duconseil en développementd’architectures webdu coaching d’équipes de développement.netdes formations surmesuresur les dernieres technologies web et open sourcevouspouvez nous contacter pour toute question:Ruimail : rui@rui.frtel : 06 10 04 70 40twitter : @rhwyThomas mail : thomas@jaskula.frtel : 06 75 60 19 52twitter : @tjaskulad’iciquelquessemainesvouspourrezretrouvernosoffres de formation surcodedistillers.fr
- #4 Retrouveznosprochainesrencontresdéveloppeurssurmeetup:www.meetup.com/altnetfrwww.meetup.com/ddd-pariswww.meetup.com/paris-software-craftsmanshipwww.meetup.com/agile-net-france
- #5 Nous sommes donc réunis ici pour parler de web apis, de framework temps réel mais aussi d’expérience utilisateur. Nous allons voir comment tout cela constitue à notre sens les fondations du web de demain et pourquoi il est impératif de comprendre et maitriser ces concepts tout d’abord puis les technologies qui vont avec.
- #6 Avant d’aller plus loin nous tenons à émettre un petit avertissement.Nous avons à traiter ici 2 sujets qui auraient pu mériter à eux seuls plusieurs sessions, nous allons nous concentrer ici sur la présentation de ces frameworks afin de vous montrer pourquoi ils sont importants et ce qu’ils apportent.
- #7 Avant d’aller plus loin dans la technique, il me parait important d’essayer de comprendre ce que celle-ci peut nous apporter.Parlons donc un peu d’expérience utilisateur.
- #8 Le monde change, cen’est pas nouveau et c’est tout cequ’onluisouhaite, mais le monde de l’information change encore plus vite
- #9 L’informatique et les réseaux de communications sontrelativementjeunes, maisilsont beaucoup évoluédepuisleur apparition.Nous sommespassésd’une infrastructure trèscentralisée non communiquanteàune infrastructure distribuée de la forme client-serveur pour arriver aujourd’huiàune infrastructure globalementconnectée avec internet. La notion de cloud apparait au sens large du termecommeunesorte de médiauniverselsurlequel tout le monde se connecte. De la mêmemanière de plus en plus de types de clients se connectent, cen’est plus uniquement le pc de bureau, maisaussi le laptop en déplacement, le smartphone et dansl’avenir de plus en plus d’objets du quotidienserontconnectés.Nous avonsdoncbesoinaujourd’hui de faire communiquer ensemble des clients complètementhétérogènes. Dansnos applications on ne peut plus uniquement se contenter de fournir des écransd’information et de saisie et cequelquecesoitce type de client
- #10 Nous sommes donc dans un monde globalement connecté ou l’information doit circuler vite et où les applications doivent savoir s’adapter aux nouveaux clients
- #11 Nous sommes passé d’applicationsoùl’on se contentait de vouloir lire des documents statiquesà des applications oul’informationestdynamique et continue commeunepluie de données. Les progrestechnologiques nous permettentaujourd’huid’avoiraccèsàcettespontanéitémaiscen’est pas la seule raison. Il s’agitaussi de fluidifier les expériences. Nous n’utilisons pas les choses de la mêmefaçon, ni ne les apprécions de la meme manièresi le résultatd’une action estimmédiatou pas. Par ex, il y a quelquesannées, je me souviens de me parents qui faisaientleurscomptes au jour le jour et confirmaient tout unefois par mois au moment de la réception du relevé de comptes. Aujourd’hui, on peutvérifier en temps réelsur le net l’état de son compte, on a l’informationimmédiatement, du coup gérermanuellementsesdépenses au quotidiensn’est plus unenécessité. Pareil, on lit peutêtremoins de magazines d’informationaujourd’hui car on se ditquel’informationimprimée sera en retard surcequel’onpeutavoirimmédiatementsur le net. Pourquoiattendred’aller en boutique acheter un cd ou film alorsque je peuxl’avoirimmédiatement en streaming.les usages changent…
- #12 Lesutilisateursveulentdoncavoirleursinformations tout de suite,nous avonsdéja beaucoup d’exemples du quotidien:- les flux d’informations temps réel, twitter, recherchesinstantanéesles cours des actions,les ventes aux enchèresles scores pendant les évènementssportifsLes notifications temps réelles jeuxinteractifsles applications collaboratives…ou meme simplement un nouvel email!
- #13 Comment répondreàcesévolutions, comment développer des applications qui s’adaptentàce monde qui change, àcesdifférentsterminaux et àcettedynamique de l’information?
- #14 Tout d’abordilfaut faire attention aux usages, et aux facteursd’interaction, convivialité ausein de l’interfaceutilisateur. Nous pouvons faire autre chose que des pages web, nous pouvonsréfléchirà la meilleuremanière de rendre un service àvaleurajoutée aux utilisateurs. Les besoins sous-jacent de ceux qui exploitent les données issues des saisies ne sont en général pas du tout les memes que les besoins des utilisateurs.
- #15 Les apisdoiventêtre le plus standard possiblesafin de faciliter les échanges avec le plus grand nombre de clients potentielsellesdoiventêtres au coeur de l’application. Tout comme les tests unitaires, ilconvient de mettre en place les apis, avant meme l’applicationou au moinsconjointement car ilestsouvent impossible de mettreunecoucheapi par dessusune application web existante.Ellesdoiventêtre simples et autonomes, l’exploitant de ces services n’est pas dans le code de votre application, ilfautqu’ilpuisse les exploiter sans se poser de questions.
- #17 veuilleznotercetteurl qui sera utilisé plus tarddansunedémo web api.
- #18 Les web services ontétéutilisédans les entreprisesdepuis des années. Ilspermettentrelativementfacilement de partager et réutiliserunelogique commune avec les différent client comme les appareils mobiles, desktop et web applications. Une API web peutêtre accessible par unevaritété des clients comme les navigateursou les appareils mobilesCela différentie les API Web d’un service SOAP traditionnel qui nécessite les clients spéciaux et une infrastructure et qui ne sont pas proche du fonctionnement d’un navigateur.
- #19 Années 2000 Salesforce, e-Bay2002 Amazon2004 Flickr2005 32 apis Facebook, Google, Twitter, Linkedin, Microsoft etc. etc. (la révolution commence)2008 1000 (Le web n’est plus ignoré dans le design des API) car SCALE est impacte autrement2012 7000Aujourd'hui 8571
- #20 Les API traditionnelles del’époqueétaient pour la plupartcréées pour assurer l’intégration des systèmes et baséessur SOAP.Ensuite de nouvelles API utilisées POX (Plain Old XML) comme format d’échange des messages et HTTP commeprotocole. Cela a permisd’atteindreune plus grandevariété des clients.A la fin les entreprise ont pris concience qu’elle ne pouvais pas ingorer le web dans le design des api car cela les empecherai de se étendre et de casser un nombre de clients important.
- #21 - RPC : Comment un client peutexécuter des procéduresdistantesà travers HTTP ?Problématique : problématiqued'intéropérabilitélié aux différents protocols, TCP, firewalls, caching, encodage des datatypes ASCII, UTF, etc.- Message : Comment un client peutenvoyer des commandes, notifications our d’autres information à un système distant à travers HTTP en évitant le couplagedirecte au procédures RPC distantes ?Problématique : problématiqued'intéropérabilité caching- Resource : Comment un client peutmanipuler les donnéesgérées par un système distant, éviter le couplagedirecte aux procéduresdistantes et minimaliser le besoind’une API centréesur un domainespécifique.
- #22 Web estorientéressourceURI identifieuniquementuneressource, maisuneressourcepeutêtreidentifiée par plusieurs URIResourceFonctionnalitéapplicatif, document, imprimenteréseau, etc.URIChaque resource estadressable par une URI unique. Scheme, Port, Path, Query (attention car non cachable)* RepresentationCopie de l'étatd'uneressourcedans le temps données != ressource. Le format de la copie et le MEDIA-TYPE (Content-type).
- #23 Intrigué par la rapidité de développement du Web les chercheurs ont commencé à étudier les raisons de son succèsRoy Fielding a écrit une thèse sur REST http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm. Il a décrit les interconnections des ressources, le rôle de leurs identifiant, les opérations et leurs sémantique qui permettent de construire une infrastructure solide qui peut supporter n'importe quelle application.
- #24 Combien de vous étaient du côté du client et que le serveur a changé et le client a été cassé ?Combien de vous voulez upgrader le serveur mais il fallait contacter tous les client pour qu’il ne soit pas cassés ?
- #25 * Level 0 servicesURI unique servant à transmettre les enveloppe à la SOAP ignorant tous les autres verbs HTTP. XML-RPC, POX. Une seule large ressource qui fait le dispatch* Level 1 servicesBeacoup de URI mais uniquement un verbe HTTP. Les noms d'opérations sont insérées dans URL (URL tunneling). Plusieurs ressources logiques* Level 2 servicesService contient beaucoup de ressources qui sont identifiable avec les URI et les verbs HTTP sont utilisés pour réaliser les opérations les plus souvent CRUD.* Level 3 servicesHATEOAS
- #26 Pour construire des applications ayant besoin de services communicant par le biais du protocole HTTP.Les applications HTMLLes applications mobilesLes applications desktop client serveur WCF était suffisant dans un environnement contrôlé de l'entreprise mais pas à l'échèle mondiale où le nombre de clients et leurs types ne sont pas connus d'avance.WCF : si l'environnement est contrôlé, si on est limité au framework .NET 3.5, si on a besoin d'exposer les service SOAP. Mais il est possible de faire un service basé sur HTTP.ASP.NET Web API => investissement de MS sur le protocole HTTP et REST contrairement à WCF où les investissement sont réalisée ailleurs.
- #27 Pour construire des applications ayant besoin de services communicant par le biais du protocole HTTP.Les applications HTMLLes applications mobilesLes applications desktop client serveur WCF était suffisant dans un environnement contrôlé de l'entreprise mais pas à l'échèle mondiale où le nombre de clients et leurs types ne sont pas connus d'avance.WCF : si l'environnement est contrôlé, si on est limité au framework .NET 3.5, si on a besoin d'exposer les service SOAP. Mais il est possible de faire un service basé sur HTTP.ASP.NET Web API => investissement de MS sur le protocole HTTP et REST contrairement à WCF où les investissement sont réalisée ailleurs.
- #28 OOTB : - IIS Hosting (HttpControllerHandler) - Self Hosting (basé sur WCF SELF hosting)La couche de hosting est un « Adaptatrur » entre Web Api architecture et une infrastructure de hosting physique.Responsabilité : - Quand la requête arrive (un callback a été enregistré), transformer la représentation native de la requête provenant de l’infrastructure en HttpRequestMessage - Quand la réponse est générer transformer HttpResponseMessage en la représentation native de la réponse d’infrastructure du hôte.
- #29 OOTB : - IIS Hosting (HttpControllerHandler) - Self Hosting (basé sur WCF SELF hosting)La couche de hosting est un « Adaptatrur » entre Web Api architecture et une infrastructure de hosting physique.Responsabilité : - Quand la requête arrive (un callback a été enregistré), transformer la représentation native de la requête provenant de l’infrastructure en HttpRequestMessage - Quand la réponse est générer transformer HttpResponseMessage en la représentation native de la réponse d’infrastructure du hôte.
- #30 Pourquoi construire les applications hypermédias ?Le client n'a pas besoin de mémoriser toutes les ressources possibles et leur emplacement 'URL' car le serveur est en charge de les générer.Le serveur peut changer l'emplacement des ses ressources et donc si le client mémorise l'URL celle-ce ne sera plus valide.Le serveur contrôle le workflow et l'enchainement de ressources car il génère le liens disponibles vers d'autres ressources en fonction de l'état actuel de la ressource. Si par exemple le bon de commande a un état 'Annulé' alors le client ne devrait pas pouvoir valider ce bon de commande (le lien ne sera pas présent).Media typesles plus populaires sont JSON et XML mais présente quelques limitations pour répresenter les liens et les forms comme HTML.Il es possible de définir ses propres liens et form mais le client doit comprendre la sémantique pour les interpréter.XHTML et ATOM HAL (http://stateless.co/hal_specification.html) étend JSON et XML pour exprimer les liens vers les ressourceset les forms ?Pour Json il y a une specification non officielle peu supportée http://json-schema.org.
- #31 Performance : Il y a meilleurs protocoles que HTTP qui est basé sur le text, synchrone, et requête/réponse comportement. MAIS HTTP = application sémantics(GET = caching, latence réduite, extensibilité horisentale)Faible couplage: Web n’embarque pas dans son stack architectural et technologique les notions comme : QOS, consistance de donnée, transactions, intégrité référentielle, statefulness, etc. Le progres peut se faire par le biais de HttpCodesWorkflow métier: pas besoin de BPEL ou WS-Choreography
- #33 Notes : pas de énormément de commentaires pour la partiesignalrmais beaucoup de slides en compensation ;-)
- #45 - Le client lance unerequêteàintervalesréguliésdéfinisle serveurrépondimmédiatementàcetterequetesiévènement arrive sur le serveur entre deuxrequetesildoit la garder en mémoire pour la renvoyerà la prochainerequête.
- #46 - On lance unerequêteLe serveur ne répondquequandil a unedonnéeàrenvoyeroualors au bout d’un temps définisiil ne s’estrien passéle client relanceunerequêtedèsqu’ilreçoit la connection du serveurLimite le traffic maiscelaconsomme des ressources de connection et de cpu (mêmesiellessont plus limitées en async)
- #47 on place uneiframedans la page avec laquelle on souhaitecommuniquerle source de cetteiframeest un fichier qui sera interprétécomme du javascriptle code javascriptestlu par le client et executé au fur et àmesure de son téléchargementle serveur ne vajamais dire au client qu’illuienvoie la fin du fichierilpousserachaquefoisqu’il aura besoin les donnéesnécédessaires sous forme de code javascriptOblige àgarderune connection active