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 :

Publicités

MS Visual Studio 2008 : Une mauvaise copie d’Eclipse

Depuis quelques jours, j’ai l’occasion d’utiliser Visual Studio 2008 à mon travail. Ceci me permet de faire quelques comparaisons avec mes outils fétiches, Eclipse et Netbeans.

Et la conclusion est désespérante pour Microsoft.

Leur produit est plus ancien mais beaucoup moins fourni, un comble.

Voici mes arguments :

  • Pas de touche magique (Le Ctrl + Shift + 1 d’Eclipse). Et oui, ces 3 touches parfaitement positinionnées qui permettent de faire pratiquement tout ce dont vous avez besoin au moment ou vous en avez besoin. Correction d’erreurs, import de classes, renommage, complétion. Avec VS 2008, rien de tout ca, vous avez la souris et son clic droit qui permettent de faire certaines choses, mais très peu en comparaison d’Eclipse.
  • Pas d’accès facile entre les classes, vous êtes obligé d utiliser le bouton droit de la souris et de faire « go to definition ». C’est lent, demande plusieurs manoeuvre et ca m’a rebuté plus d’une fois.
  • Génération de code laborieuse. Il est difficile de trouver les générateurs de code (genre get/set), et les complétions de code se génèrent souvent sans les parenthèses nécessaires aux appels de méthodes (vides) ou sans les accolades de fin des méthodes ou blocs conditionnels. Vous êtes donc toujours obligés de fermer les accolades, VS 2008 ne le fait pas pour vous.
  • Mise à jour des erreurs très tardives parfois. VS 2008 vous indique des erreurs, assez bien, même si on aurait aimé un affichage plus lisible, mais lorsque vous corrigez ces erreurs, celles-ci restent affichées jusqu’au prochain lancement du serveur. Ce n’est pas très agréable de chercher une erreur alors que vous venez de la corriger.
  • Documentation avec peu d informations. Je crois que c’est le pire. Microsoft vous fournit une grosse documentation sur MSDN, mais pour trouver un type en entrée ou en sortie d’appels de méthodes, il faut écrire la méthode dans l’éditeur pour le savoir. C’est plutôt moyen. Quand on compare avec la javadoc, on s’aperçoit vite que MS fait beaucoup moins bien dans ce domaine. J’avais trouvé une doc assez complète dans la MSDN, j’allais féliciter MS pour ces progrès et finalement il s’agissait de documentation java. Y’a pas à dire (faudra m’expliquer ce que fait la documentation java dans MSDN).
  • Utilisation brouillon des génériques. MS a fait pareil que Java en rajoutant des génériques sur ses types. Mais pourquoi faire simple quand on peut faire compliquer. Ce sont de nouveaux types, extensions des anciens mais dans d’autres packages et avec des fonctionnalités parfois différentes. Ce qui implique des imports différents, des utilisations différentes de type en fonction du contexte de programmation. Au final, on est vite perdu dans leur utilisation. Mais pourquoi n’ont-ils pas fait comme java ? Les mêmes types mais on autorise la généricité…
  • Fonctionnement de l’éditeur différent en fonction du langage. Et oui, l’éditeur ne se comporte pas de la même façon si vous développez en VB ou en C#. La complétion par exemple, avec la touche entrée, dans un cas, elle vous renvoie à la ligne, dans l’autre elle vous laisse après le bloc compléter. Ceci s’explique surement par des raisons historiques, mais c’est quand même bien dommage.
  • Pas de surbrillance des éléments. C’est une fonction bien agréable d’Eclipse. Vous placez le curseur sur une variable, une méthode, une exception et Eclipse vous montre son utilisation dans le code. C’est particulièrement pratique pour voir les références dans le code. Sous VS 2008, cette fonctionnalité n’explique tout simplement pas. Une horreur lorsqu’on a pris l’habitude de l’utiliser.
  • Presque pas de couleur. L’éditeur de MS ne fournit quasiment pas de couleur pour la syntaxe. Beaucoup de noir, un peu de bleu clair, un peu de bleu foncé et du vert pour les commentaires, c’est tout. Pas de mise en gras ou de souligné, pas d’autres couleurs. Ca rend le code peu lisible et peu engageant.
  • Une documentation en pseudo HTML avec des balises limitées. La javadoc .Net se crée avec des balises style HTML <summary> qui sont à moitié généré. A moitié car les fins de balise sont à écrire à la main. Déjà que les développeurs n’aiment pas écrire la documentation dans le code, avec VS 2008, on dirait que MS a fait exprès de les rebuter au maximum. En plus, il n’existe qu’un nombre très limité de balise et pas de author, since ou version. Comment voulez-vous faire dans ces conditions ?

Avec tous ses défauts, on se demande ce qu’on peut trouver à VS 2008. L’éditeur a 2 ans de retard sur ses concurrents directs (Eclipse et Netbeans). Il apprend et copie des autres, mais vraisemblablement pas assez vite.

Et avec tout ca, on vous raconte que l’environnement .Net vous permet d’être plus productif. Il va falloir me donner des arguments pour me le prouver !!

Heureusement j’ai lu qu’Eclipse allait permettre d’écrire du code .Net. Voila une très grosse concurrence pour VS2008. Vite c’est où qu’on récupère le plugin ?!!!

%d blogueurs aiment cette page :