J'ai fait un peu de travail dans le passé en utilisant WCF WebAPI et j'ai vraiment aimé beaucoup de ses caractéristiques, je joue juste avec ASP.NET Web API en ce moment et il semble complètement différent (IE complètement éloigné de WCF).
Quelqu'un sait-il quelles fonctionnalités de WCF WebAPI sont incluses dans ASP.NET 4 Web API ?
J'ai fait un peu plus de lecture à ce sujet et j'ai trouvé quelques pages rédigées par des personnes de l'EM à ce sujet :
Les abstractions de l'API Web WCF correspondent grosso modo à l'API Web ASP.NET comme suit
WCF Web API -> ASP.NET Web API
y http://wcf.codeplex.com/discussions/319671
La pile intégrée prend en charge les fonctions suivantes :
D'après ce que j'ai appris, Microsoft a un peu confondu les noms.
Je suppose que vous savez ce qu'est WCF, ce grand cadre construit sur XML pour permettre aux utilisateurs de construire des services distribués avec une grande variété de technologies (de SOAP à REST en passant par MSMQ, etc.).
Il est très difficile à utiliser (pour moi en tout cas) et nécessite beaucoup d'efforts pour le faire fonctionner. Ils ont fini par s'en rendre compte et ont commencé à fournir une configuration par défaut pour des services http simples (WCF REST starter kit, quelqu'un ?). ASP.NET MVC prenait de l'ampleur et certaines des fonctionnalités qu'il offrait (la correspondance automatique des arguments par exemple) ont commencé à apparaître dans WCF.
Telle est la situation :
Annonce : WCF Web API devient ASP.NET Web API ! ASP.NET Web API a été lancée avec ASP.NET MVC 4 Beta. L'API Web WCF et la prise en charge WCF de jQuery sur ce site seront supprimés d'ici la fin de l'année 2012.
http://wcf.codeplex.com/wikipage?title=Getting%20started:%20Building%20a%20simple%20web%20api
Et c'est mieux ainsi.
Je suis certain qu'il devrait être possible d'héberger le webapi asp.net mvc4 au-dessus de WCF (si jamais vous en avez besoin), mais je n'arrive pas à trouver de documentation qui me donne raison (ou tort).
MISE À JOUR (ne peut être inséré en tant que commentaire) : Attendez, il y a une énorme différence entre "déplacer un sous-ensemble de technologie de communication d'une bibliothèque/framework à une autre" et "remplacer WCF". Personnellement, je pense que WCF a été conçu pour un certain type de concept de communication et qu'il a un design plutôt cool, mais l'informatique distribuée évolue vers de nouvelles (et plus simples) solutions (regardez le SOAP riche en fonctionnalités contre le REST léger et flexible, bien que beaucoup de gens utilisent encore REST d'une manière RPC), et je pense que ce type de modèle de programmation s'intègre mieux dans l'architecture MVC que dans l'architecture WCF. Des efforts ont été déployés pour concevoir un moyen simple de construire/consommer des services web au-dessus de WCF, mais ils ont finalement découvert que ce n'était pas la bonne solution.
Sans oublier que de nombreux développeurs utilisent désormais ASP.NET MVC et veulent mettre en place des services web de repos pour leur application web, s'amuser avec WCF est souvent exagéré pour ce genre de choses, et j'en ai fait l'expérience moi-même.
Je pense que le mécanisme de routage est génial et que c'est la bonne façon de faire, et si vous regardez bien, ils ont inclus une partie de ce mécanisme (avec des noms et des types différents, mais le modèle était là) dans WCF. Donc oui, je pense que si MS ne rejette pas cette partie de WCF WE devrait le faire. Pour répondre strictement, non, je ne pense pas que vous trouverez jamais WebGet/WebInvoke dans asp.net mvc*, ce n'est tout simplement pas adapté.
Oui, le self-host est probablement le seul élément de WCF contenu dans ASP.NET MVC4 à l'heure actuelle.
Oui, d'après ce que je sais, l'API Web de MVC4 est conçue pour remplacer directement l'API Web de WCF. Mais je ne suis pas très sûr de la manière dont cela fonctionne, car elle semble être fournie par ASP et non par WCF, ce qui est un peu bizarre. ASP est-il censé remplacer WCF ? Je ne suis pas non plus très sûr des éléments de WCF WebAPI qui sont inclus dans le nouveau produit, j'ai remarqué que le client de test n'est pas encore là, mais je m'interrogeais aussi sur les différences dans le routage (et d'autres domaines), le routage ASP.Net est-il censé remplacer les extensions WebInvoke pour WCF WebAPI ou sont-elles encore là quelque part ?
Je ne suis pas très sûr de ce que vous entendez par "Je suis tout à fait sûr qu'il devrait être possible d'héberger asp.net mvc4 webapi au dessus de WCF" ils me semblent un peu mutuellement exclusifs, voulez-vous dire 'Self Hosting' ?
En gros, ce que vous dites, c'est que le composant SOAP de WCF reste WCF, mais que le composant REST a été déplacé vers ASP.
Il semble que WCF lui-même soit en train de mourir ou du moins de devenir beaucoup moins important que ce qu'il était censé être et, pour cette raison, il y a également beaucoup moins d'efforts de développement dans son ensemble de fonctionnalités. Nouvelles fonctionnalités de WCF sont plus cosmétiques.
WCF a été conçu comme un moyen indépendant du transport et du protocole pour la communication interprocessus. Même si l'idée était une abstraction indépendante, elle était principalement construite sur la pile SOAP. Lorsque WCF 3.5 a apporté la prise en charge de REST, elle a été principalement piratée parce que REST est lié à la dépendance vis-à-vis du transport. L'utilisation d'une API indépendante du transport pour prendre en charge la communication interprocessus, qui se fait en utilisant directement les fonctions de transport, n'est pas apparue comme une solution pratique. En conséquence, MS a d'abord publié le WCF Rest API Starter Kit, qui n'a jamais atteint la version RTM, mais qui présentait en avant-première des fonctionnalités qui ont ensuite été incluses dans WCF 4 et enfin dans .NET 4.5 ou WCF Web API. REST étant dépendant du transport et actuellement utilisé uniquement avec HTTP (même s'il est théoriquement possible d'utiliser d'autres protocoles de transport), l'API a été déplacée vers la partie de .NET qui est plus adaptée au traitement HTTP - vers le très populaire ASP.NET MVC.
WCF avait pour but de faire abstraction de HTTP, TCP, etc. La pile REST, quant à elle, utilise HTTP. La séparation des deux est donc une excellente décision pour que WCF reste une pile de services purement neutre du point de vue du protocole.
-1 : l'api web "ASP.NET" n'est pas une raison de croire que WCF est en train de mourir ou de perdre de son importance. C'est une raison de croire que le marché cible des services REST n'est pas le marché cible de WCF.
L'API Web WCF est remplacée par l'API Web ASP.NET qui reprend les fonctionnalités de l'API Web WCF et les fusionne avec les fonctionnalités de ASPNet MVC. ASP.NET Web API est un nouveau cadre (02/2012) pour la création et la consommation de services HTTP et une plateforme pour la création de services RESTful.
Bien que cela ne fasse pas partie de la question initiale, il semble utile de noter que WCF est bien vivant et que son support REST reste utile lorsque vous avez des services SOAP (WS-*) existants que vous devez supporter mais que vous souhaitez ajouter REST pour atteindre plus de clients.
Référence
L'extrait suivant se trouve sur cette page MSDN résume bien ce dilemme.
Utiliser WCF pour créer des services web fiables et sécurisés accessibles via une variété de transports. Utilisez ASP.NET Web API pour créer des services basés sur HTTP qui sont accessibles à partir d'une grande variété de clients. Utilisez ASP.NET Web API si vous créez et concevez de nouveaux services de type REST. Bien que WCF offre une certaine prise en charge de l'écriture de services de type REST, la prise en charge de REST dans ASP.NET Web API est plus complète et toutes les améliorations futures des fonctionnalités REST seront apportées à ASP.NET Web API. Si vous disposez d'un service WCF existant et que vous souhaitez exposer des points d'extrémité REST supplémentaires, utilisez WCF et le WebHttpBinding.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
4 votes
Il ne s'agit pas d'une WebAPI MVC, mais d'une API Web ASP.NET qui n'est en aucun cas couplée à ASP.NET MVC. Voir ce billet de blog : blogs.msdn.com/b/henrikn/archive/2012/02/23/ Vous pouvez également l'héberger vous-même si vous le souhaitez.