Appeler un Web Service REST/JSON en .NET

Les Web Services REST avec le format JSON sont devenus en peu de temps un nouveau moyen d’implémenter des Web Services de manière simple (sans formatage XML et parsing) et orientés données.

Si la procédure de création de Web Services RPC ou REST et SOAP ou JSON en .Net est simplifiée grâce à WCF, et que l’appel d’un Web Service RPC/SOAP est quasi transparent pour le développeur, il n’en est pas de même pour la création du client en REST/JSON.

Ce petit post va vous permettre de mettre en place rapidement un client Web Service .NET avec REST/JSON. Je fais l’impasse sur l’implémentation serveur, je vous laisse vous référer aux différents liens placés en fin de billet.

  • Ajoutez une référence a votre Web Service dans votre projet VS et pointez sur votre URL de type : www.monsite.com/monservice.svc
    • Cet étape va générer votre client Web Service, mais surtout ce qui nous intéresse, les objets en transit,
  • Ajoutez JSON.NET dans votre projet afin de déserialiser vos données automatiquement,
  • Implémentez le code suivant :
Uri requestUri = new Uri("www.monsite.com/monservice.svc/users/5474");
WebRequest webRequest = WebRequest.Create(requestUri);
WebResponse webResponse = webRequest.GetResponse();
Stream response = webResponse.GetResponseStream();
StreamReader reader = new StreamReader(response);
Newtonsoft.Json.JsonSerializer jsonSer = new Newtonsoft.Json.JsonSerializer();
MyUser user = (MyUser) jsonSer.Deserialize(reader, typeof(MyUser));
  • Vous obtenez ainsi votre objet côté client, il ne vous reste plus qu’à en faire bon usage,
  • Vous pouvez également récuperer une liste ou un tableau d’objets avec le code suivant :
List<MyUser> usersList = (List<MyUser>)jsonSer.Deserialize(reader, typeof(List<MyUser>));

Je vous conseille fortement de créer une méthode générique avec 3 parametres (URL, type de résultat et résultat) afin de pouvoir réutiliser ce code a loisirs.

Update : Vous avez également la possibilité de ne pas utiliser JSON.NET avec le Serializer intégré dans .Net 3.5

DataContractJsonSerializer jsonSer = new DataContractJsonSerializer(typeof(List<MyUser>));
List<MyUser> usersList = (List<MyUser>)jsonSer.ReadObject(response);

Après quelques tests, il semblerait que le parser de MS soit le plus rapide. Cependant cette page semble donner plus d’informations concrètes :

La qualité est un voyage

pas une destination.

C’est par ces mots que se termine la conférence Qualité du code source et l’intégration continue des collaborateurs de Xebia. Il est bon de rappeler que la qualité ne peut pas être quelque chose qui s’enclenche en un geste, ni même qu’elle se termine.

Au cours de ma carrière, j’ai souvent été surpris par le peu de qualité fournie sur les projets, tant au niveau du code source que de la documentation. Et ne parlons pas des tests ou de l’intégration continue, concepts encore trop souvent inconnus chez certains éditeurs.

Mais instaurer la qualité sur un projet existant ou dans une société n’est pas chose aisée. Xebia le détaille d’ailleurs très bien sur les dernières diapositives de son exposé.

Pour ma part, je dirais que la plus grosse difficulté n’est pas sur la technique, puisque qu’après tout, si d’autres sociétés le font, tout le monde peut le faire, mais sur les individus et la motivation.

En effet, si les participants au changement ne connaissent pas ces pratiques, ils peuvent douter de leurs biens fondés, de la facilité de mise en place, des gains de productivité et qualité et de l’impact direct sur leur travail.

Imaginez, vous demandez à des développeurs, souvent en place depuis plusieurs années de :

  • changer leur façon de développer, cela pourrait laisser penser qu’ils ne savent pas développer,
  • écrire des tests unitaires et d’intégration, ce qui va leur demander plus de temps, et donc faire baisser leur productivité,
  • suivre leur projet sur un serveur d’intégration et corriger toute erreur en priorité si le cas se présente, ce qui signifie que corriger un serveur de build est plus important qu’une fonctionnalité métier,

Il est clair que si l’on évoque ces trois points, la qualité du code source et l’intégration continue ne semblent pas apporter de productivité aux développements, bien au contraire.

Mais lorsqu’on connait les 3 points suivants, les premiers commentaires semblent bien négligeables, face aux avantages accumulés :

  • Un développeur passe 80% de son temps à lire du code et 20% à en écrire, il a donc tout intérêt à avoir un code lisible et rapidement compréhensible, pour diminuer son temps de lecture et augmenter son temps d’écriture,
  • Les tests permettent d’être informé de la moindre régression dans le code et de modifier à loisirs et sans doute du code existant afin de l’améliorer,
  • Le serveur de build informe, en temps quasi-réel, de l’état du projet et des tests pour l’ensemble des acteurs du projet, afin de corriger une erreur au plus tôt et de ne pas attendre d’être en production pour corriger une faille passée au travers des tests métiers,

Pour une société qui ne maitrise aucun des points cités précédemment, les gains de productivité peuvent atteindre 300%, voire plus si le code est réellement catastrophique ou si l’intégration de nouveaux développeurs est importante. Vous me direz alors, 300%, c’est énorme. En fait à y réfléchir, ces 300% ne sont pas très important, c’est principalement la productivité de départ qui est très faible. Car bien souvent, si vous n’avez pas de qualité du source code ou d’intégration continue, vous empilez les bugs, vous multipliez les copier-coller de peur de modifier l’existant, vous passez votre temps à lire et vérifier une implémentation…

Mais rappelez-vous, pour mettre en place les bons process de développements, le plus important n’est pas la technique, c’est l’accompagnement au changement. Soyez sur d’avoir les bonnes personnes pour vous aider.

Plugin Firefox : Greasefire et Google Fx

Et oui, encore 2 petits plugin firefox. Enfin pas tout à fait. Le premier est un plugin firefox, le second un script greasemonkey. Dans tous les cas cependant, il vous faudra firefox.

Greasefire : Découvrez les scripts GreaseMonkey

Greasefire est un plugin firefox qui permet au fil des sites sur lesquels vous surfez, de vous informer des scripts disponibles pour ceux-ci. Vous pouvez donc surfer normalement et si le site sur lequel vous vous trouvez permet d’utiliser des scripts GreaseMonkey, greasefire vous l’indiquera et vous fournira directement dans Firefox une petite interface pour découvrir le script et l’installer. Un must lorsqu’on souhaite personnaliser son surf.

Affichage des scripts disponibles sur le site courant

Affichage des scripts disponibles sur le site courant

Google Fx : Personnaliser votre recherche Google

Google Fx quant à lui est un script GreaseMonkey, qui vous permet de personnaliser la page de résultat Google afin d’afficher plus que la simple recherche de site proposée par Google. Vous y retrouverez Wikipedia, Google Images, Google Video, des liens vers d’autres moteurs de recherche, triés par catégorie, filtrable sur le titre, le contenu, la date… Un vrai bonheur pour celui qui souhaite voir organiser ses résultats. Mais attention cependant, ce petit script ralentira légèrement l’affichage des résultats. C’est perceptible mais pas réellement gênant.

Affichage de la page de résultat Google avec le script Google Fx

Affichage de la page de résultat Google avec le script Google Fx

Pour la forme, je vous rappelle mes propres scripts GreaseMonkey :

Suivre

Get every new post delivered to your Inbox.