Introduction à ASP.NET WebAPI (partie 1)

Dans ce billet, mon but est de vous initier à ASP.NET WebAPI de Microsoft, permettant facilement d'ouvrir vos données vers l'extérieur.
Bien que WebAPI fasse partie intégrante d'ASP.NET MVC 4, lors de la réalisation de cet article je n'avais accès qu'à une machine sous Vista SP1. Etant donné les problèmes de compatibilité de cette ancêtre avec les dernières versions des outils Microsoft (Visual Studio ou ASP.NET MVC), j'ai été contraint de travailler avec ASP.NET MVC 3 et d'ajouter (via NuGet) les références à WebAPI.
Je vous propose donc de découvrir comment fonctionne WebAPI sous Visual Studio 2010, via la création d'un projet "serveur" qui va héberger mon API. Dans un futur billet, je vous montrerai comment créer simplement un client utilisant jQuery pour consommer cette API.

Prérequis

Comme je l'explique plus haut, tout est plus simple (car complétement intégré) avec ASP.NET MVC 4.
Mais dans mon cas, c'est incompatible, alors si vous êtes sur Vista SP2 ou +, vous pouvez passer directement au chapitre suivant et créer un projet ASP.NET MVC 4 de type WebAPI. Si ce n'est pas le cas, ou que vous devez utiliser ASP.NET MVC 3 voici ce qu'il vous faut :

  • Visual Studio 2010
  • .NET Framework 4.0
  • ASP.NET MVC 3
  • NuGet pour Visual Studio

Création du projet

Commençons donc notre découverte de WebAPI par la création d'un nouveau projet. Pour ma part, ce sera un projet ASP.NET MVC 3, mais si vous en avez l'occasion, facilitez-vous la vie et créez directement un projet ASP.NET MVC 4 :
Nouveau_projet_MVC3
On arrive alors sur l'écran de sélection du template à appliquer à notre projet. Si vous êtes en ASP.NET MVC 4, allez directement sur le template nommé WebAPI, mais si vous êtes en version 3, libre à vous de choisir votre template (j'utilise Intranet Application dans cette démonstration) :
Template intranet
Voilà, votre site de base est prêt, passons maintenant au controller WebAPI.

Votre premier APIController

Comme pour le reste de l'article, les choses sont différentes selon la version d'ASP.NET MVC et le template utilisés. Pour MVC 4 et le template WebAPI, passez directement au test à la fin de ce chapitre. Pour les malheureux en MVC 3, il nous faut maintenant ajouter le package NuGet Microsoft.Asp.Net.WebAPI. L'utilisation (archi simple) de NuGet n'étant pas l'objet de cet article, je vous laisse faire vos recherches. Une fois cette étape terminée, faites un clic-droit sur le dossier Controllers de votre application et ajoutez un nouvel élément. Nous allons choisir le template WebAPI Controller Class et le nommer BlogPostController :
Nouveau controlleur WebAPI
Vous devriez obtenir le code suivant :
Controller par defaut
Afin de pouvoir tester tout de suite ce controller, et ce uniquement si vous êtes en ASP.NET MVC 3 (la modification étant faite de base en MVC 4), rendez-vous dans le code du fichier Global.asax et modifiez la méthode RegisterRoutes comme sur l'image ci-dessous :
Global.asax
Ces quelques lignes permettent de rediriger toutes les requêtes contenant {monSite:port}/api/{controller} vers l'APIController correspondant. Il ne reste plus qu'à tester ! Lancez donc votre application via F5, et ajoutez /api/BlogPost à votre URL (ou /api/values pour l'APIController par défaut des projets WebAPI ASP.NET MVC 4). Vous devriez obtenir ceci :
Controller par defaut result
En fait, WebAPI se sert du verbe HTTP utilisé dans la requête ainsi que de l'URL pour trouver le bon controller et la bonne méthode. Dans notre cas, on appelle notre site avec /api/BlogPost, ce qui va rediriger la requête vers BlogPostController (grâce aux lignes que nous avons ajoutées dans le Global.asax), c'est la partie URL. Pourquoi n'utilise-t'on pas /api/BlogPostController ? C'est tout simplement une convention en ASP.NET MVC, tous les controllers doivent être suffixés par Controller. Ensuite, on utilise le verbe HTTP, ici, j'ai simplement saisi une URL, le verbe est donc GET. Comme je n'ai pas précisé de paramètre après BlogPost, la requête est redirigée vers la première méthode de mon controller. Avec une URL comme ceci : /api/BlogPost/1, la seconde méthode aurait été appelée. Avec des verbes différents (POST, PUT, DELETE), ce sont les autres méthodes de mon controller qui auraient été utilisées.

Création du modèle

Afin de respecter le modèle MVC (Model-View-Controller) nous allons créer un modèle pour notre API. Rien de bien méchant pour cette démo, juste un petit objet BlogPost contenant quelques informations basiques qui sera placé dans le dossier Models de notre application :
Model
Afin de pouvoir tester au mieux mon futur BlogPostController, je vais également gérer la persistance avec un DbContext qui sera lié à une base de données. Cette fois encore, l'objet de cet article n'est pas de montrer le fonctionnement d'EntityFramework ou de LinqToSQL, je vous laisse donc gérer cette partie de votre côté, et vous propose juste de jeter un œil aux quelques lignes qui permettent, de façon extrêmement simple, de gérer cet aspect en .NET :
WebAPIServerContext
J'ai également ajouté deux billets de blog dans ma base de données, afin de démontrer le fonctionnement de mon futur controller 🙂

BlogPostController

Nous y voilà, enfin, le développement de notre premier vrai APIController, fonctionnant avec un objet métier. Pour ceux qui sont en MVC 3, on va éditer notre fichier BlogPostController.cs, pour les autres, ajoutez un nouveau WebAPI Controller à votre projet dans le dossier Controllers. Comme je l'expliquais plus haut, il existe 5 méthodes dans un controller WebAPI :

  1. Get (sans paramètre) => récupération de tous les éléments
  2. Get (avec paramètre) => récupération d'un élément particulier
  3. Post => ajout d'un élément
  4. Put => mise à jour d'un élément
  5. Delete => suppression d'un élément

Il va nous falloir implémenter ces 5 méthodes pour offrir toutes les possibilités CRUD à notre API. Voici le code :
BlogPostController part1
BlogPostController part2
BlogPostController part3
Encore une fois, et je pense notamment à la méthode Put, il existe plusieurs façons d'implémenter la mise à jour (copie, attachement au contexte ...) mais là n'est pas le sujet de ce post. Comme je l'ai dit précédemment, pour les besoins de la démo, j'ai ajouté plusieurs billets dans ma base de données. Testons donc notre APIController en lançant l'application via F5, ce qui devrait vous donner quelque chose comme ça :
BlogPostController XML result
Comme vous le voyez mes objets BlogPost sont sérialisés au format XML. Ceci n'est pas une limitation de WebAPI, bien au contraire ! C'est en réalité votre navigateur qui demande les résultats sous ce format, car il sait l’interpréter facilement.

Conclusion

Nous avons vu comment créer un premier APIController avec WebAPI, et comment fonctionnaient ces controllers avec les verbes HTTP. Dans un prochain article, nous allons créer un site "client" qui va consommer notre API afin de consulter, d'ajouter, de modifier et de supprimer des billets de blog. Ce site utilisera jQuery pour les appels au "serveur" que l'on vient de développer, et demandera les informations au format JSON pour plus de simplicité et de légèreté dans les échanges.

2 commentaires

  1. hello there and thank you to your info ? I have definitely picked up anything new from right here. I did alternatively experience several technical issues the usage of this website, since I skilled to reload the web site a lot of instances prior to I may just get it to load correctly. I have been puzzling over in case your web hosting is OK? No longer that I am complaining, however sluggish loading instances times will sometimes have an effect on your placement in google and could harm your high quality ranking if ads and marketing with Adwords. Well I am adding this RSS to my email and can look out for a lot extra of your respective interesting content. Ensure that you update this again very soon..

  2. hello there and thank you to your info ? I have definitely picked up anything new from right here. I did alternatively experience several technical issues the usage of this website, since I skilled to reload the web site a lot of instances prior to I may just get it to load correctly. I have been puzzling over in case your web hosting is OK? No longer that I am complaining, however sluggish loading instances times will sometimes have an effect on your placement in google and could harm your high quality ranking if ads and marketing with Adwords. Well I am adding this RSS to my email and can look out for a lot extra of your respective interesting content. Ensure that you update this again very soon..

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.