Le choix du type de service : WCF vs Web API
WCF est un Framework de communication de Microsoft. Une application WCF permet de bâtir et de faire communiquer des services basés sur le protocole SOAP. Il succède au service de type ASMX. Les services WCF permettent également de mettre en œuvre une architecture REST mais Microsoft propose depuis 2012 un nouveau type d’application : les Web API.
ASP.Net WebAPI est apparu avec ASP.Net MVC 4. C’est la solution proposée par Microsoft pour permettre aux développeurs de construire rapidement des services web REST. La principale différence entre WebAPI et MVC est que l’un possède des vues alors que l’autre retourne des données sérialisées (JSON/XML).
Avec l’avènement de .NET Core, Microsoft a fusionné les produits ASP.Net MVC et ASP.Net WebAPI. Les classes a manipuler pour développer des projets de type WEB API ou MVC sont maintenant les mêmes !
MSDN nous indique : « Utilisez WCF pour créer des services Web dignes de confiance et sécurisés accessibles via un large éventail de transports. Utilisez l’API Web ASP.NET pour créer des services HTTP qui sont accessibles à partir d’une large gamme de clients.
Utilisez l’API Web ASP.NET si vous créez et concevez de nouveaux services REST. Bien que WCF prenne en charge l’écriture de services REST, la prise en charge de REST dans l’API Web ASP.NET est plus complète et toutes les futures améliorations des fonctionnalités REST seront apportées dans l’API Web ASP.NET. »
Bien sûr au sein d’un SI ilest tout à fait possible d’utiliser les deux approches suivant les besoins propres au projet. WCF est historiquement lié au service SOAP et bien qu’apte à l’implémentation de service REST il me parait trop lourd pour la réalisation de micrososervices.
Le choix du langage : .Net Core ou .Net
Sous l’impulsion de Satya Nadella, et les nécessités d’un cloud Azure ouvert à tous les OS et à tous les langages, le projet « .NET 5 » s’est transformé en un runtime cross-plateforme et open-source connu sous le nom de « .NET Core ».
Pour des soucis de performances .Net Core semble mieux indiqué de pars sa légèreté et facilité de déploiement.
Microsoft nous propose :
« Utilisez .NET Core pour votre application serveur quand :
- Vous avez des besoins multiplateformes ;
- Vous ciblez des microservices ;
- Vous utilisez des conteneurs Docker ;
- Vous avez besoin de systèmes scalables et hautes performances.
- Vous avez besoin de versions .NET côte à côte par application.
Utilisez .NET Framework pour votre application serveur quand :
- Votre application utilise le .NET Framework (nous vous recommandons de privilégier l’extension à la migration).
- Votre application utilise des packages NuGet ou des bibliothèques .NET tiers non disponibles pour .NET Core.
- Votre application utilise des technologies .NET non disponibles pour .NET Core.
- Votre application utilise une plateforme qui ne prend pas en charge .NET Core. »
Parenthèse sur le projet .Net Standart : Il s’agit d’une spécification pour garantir qu’une librairie de code .Net fonctionne sur toutes les plateformes. .Net Standart est donc un jeu d’API que les implémentations .Net (.Net Framework / .Net Core / Xamarin) doivent respecter pour garantir la portabilité de la librairie développée. Ce projet s’inscrit bien sûr dans la volonté de Microsoft de s’ouvrir aux autres plateformes : Linux, MacOs, Android et iOS.
Pour pouvoir développer en .Net Core sur les plateformes autre que Windows, Microsoft nous propose un nouvel IDE, léger, modulaire et OpenSource : https://code.visualstudio.com/. En contrepartie, ces fonctionnalités sont bien plus limitée que Visual Studio 2017.
Pour le développement de microservices en .Net la combinaison optimale me semble donc être Web API REST + .Net Core. Ce duo convient parfaitement aux besoins de légèreté, rapidité et modularité de notre architecture !