Quelle est la différence entre l'API Web WCF et l'API Web ASP.NET?
Par le passé, j'ai utilisé un peu de travail avec WCF WebAPI et j'ai beaucoup aimé ses fonctionnalités. Je ne fais que jouer avec l'API Web ASP.NET pour le moment et cela semble complètement différent (IE complètement supprimé de WCF).
Est-ce que quelqu'un sait quelles fonctionnalités de WCF WebAPI sont incluses dans l'API Web ASP.NET 4?
J'ai lu un peu plus sur ce sujet et j'ai trouvé quelques pages de personnes atteintes de SP:
Les abstractions de l'API Web WCF mappent à l'API Web ASP.NET à peu près comme suit
API Web WCF -> API Web ASP.NET
- Service -> contrôleur API Web
- Opération -> Action
- Contrat de service -> Non applicable
- Endpoint -> Non applicable
- Modèles d'URI -> Routage ASP.NET
- Gestionnaires de messages -> Same
- Formatters -> Idem
- Opérateurs -> Filtres, classeurs de modèles
et http://wcf.codeplex.com/discussions/319671
La pile intégrée prend en charge les fonctionnalités suivantes:
- Modèle de programmation HTTP moderne
- Prise en charge complète du routage ASP.NET
- Négociation de contenu et formateurs personnalisés
- Modèle de liaison et de validation
- Les filtres
- Composition de la requête
- Test facile à l'unité
- Inversion de contrôle améliorée (IoC) via DependencyResolver
- Configuration basée sur le code
- Auto-hôte
Il semble que la WCF elle-même est en train de mourir ou au moins de devenir beaucoup moins importante qu’elle ne le devait. C’est pourquoi elle a également déployé beaucoup moins d’efforts de développement. Les nouvelles fonctionnalités de WCF lui-même sont plus esthétiques.
WCF a été conçu comme un moyen de transport/protocole indépendant pour la communication interprocessus. Même l'idée était une abstraction indépendante, elle était principalement construite sur la pile SOAP. Lorsque WCF 3.5 apportait la prise en charge de REST, il s'agissait principalement de piratage, car REST concernait uniquement la dépendance de transport. L'utilisation d'API indépendante du transport pour prendre en charge la communication inter-processus effectuée directement à l'aide de fonctions de transport semblait peu pratique. En conséquence, MS a publié pour la première fois le kit de démarrage de l’API WCF Rest qui n’atteignait jamais RTM mais constituait un aperçu des fonctionnalités qui ont ensuite été incluses dans WCF 4 et enfin dans .NET 4.5 ou API Web WCF. Étant donné que REST dépend du transport et est actuellement utilisé uniquement avec HTTP (même s'il est théoriquement possible d'utiliser un autre protocole de transport), l'API a été déplacée vers la partie .NET qui convient mieux au traitement HTTP - actuellement très populaire ASP.NET. MVC.
D'après ce que j'ai appris, Microsoft a fait un peu de confusion en nommant ici.
Je suppose que vous savez ce qu'est la WCF, ce grand framework construit sur XML pour permettre à l'utilisateur de créer des services distribués avec une grande variété de technologies (de SOAP à REST à MSMQ, etc.). ).
Il est difficile à utiliser (du moins pour moi) et nécessite beaucoup d'amorçage pour que cela fonctionne, et finalement ils l'ont compris et ont commencé à fournir une configuration par défaut pour des services http simples (Kit de démarrage WCF REST?) . ASP.NET MVC prenait de l'ampleur et certaines des fonctionnalités fournies (arguments automatiques correspondants, par exemple) ont commencé à apparaître dans WCF.
Maintenant c'est la situation:
Annonce: L'API Web WCF est maintenant l'API Web ASP.NET! API Web ASP.NET publié avec ASP.NET MVC 4 Beta. L'API Web WCF et le support WCF pour Le contenu de jQuery sur ce site sera supprimé d'ici la fin de 2012.
http://wcf.codeplex.com/wikipage?title=Getting%20started:%20Building%20a%20simple%20web%20api
Et c'est mieux à mon humble avis.
Je suis tout à fait sûr qu'il devrait être possible d'héberger asp.net mvc4 webapi en plus de la WCF (si vous en avez besoin), mais je ne trouve pas de documentation qui puisse prouver que j'ai raison (ou tort).
UPDATE (ne peut pas contenir de commentaire): Attendez, il y a une énorme différence entre "déplacer un sous-ensemble de technologies de communication d'une bibliothèque/d'un framework à un autre" et "remplacer le WCF". Personnellement, je pense que WCF a été conçu pour une sorte de concept de communication et qu’il a un design plutôt cool, mais l’informatique distribuée évolue quelque peu vers de nouvelles solutions (plus simples) (regardez le riche en fonctionnalités SOAP par rapport au lean Le REST flexible, bien que beaucoup de gens utilisent encore REST de manière RPC), et je pense que ce type de modèles de programmation s’intègre mieux à l’architecture MVC que celle basée sur WCF. Des efforts ont été déployés pour concevoir un moyen simple de créer/consommer des services Web en plus de WCF, mais ils ont finalement découvert que ce n'était pas la bonne solution.
Sans compter que de nombreux développeurs utilisent maintenant ASP.NET MVC et souhaitent utiliser des services Web de repos pour leur application Web. Le fait de jouer à WCF est souvent excessif pour ce genre de choses, et j'en ai fait l'expérience sur mon propre skin.
Je pense que le mécanisme de routage est génial et que la bonne façon de procéder, et si vous regardez de plus près, ils en ont inclus une partie (avec des noms et types différents, mais la tendance était là) dans WCF. Donc oui, je pense que si MS ne rejette pas cette partie de la WCF , NOUS devrions le faire. Pour répondre strictement, non, je ne pense pas que vous trouverez jamais WebGet/WebInvoke dans asp.net mvc *, cela ne rentre tout simplement pas.
Ouais, self-Host est probablement le seul élément de WCF contenu dans ASP.NET MVC4 pour le moment.
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 d'ASPNet MVC. L'API Web ASP.NET est une nouvelle infrastructure (02/2012) permettant de créer et de consommer des services HTTP et une plate-forme permettant de créer un service RESTful.
Bien que cela ne figure pas dans la question initiale, il semble utile de noter que la WCF fonctionne bien et que sa prise en charge REST reste utile lorsque vous disposez de services SOAP (WS- *) existants que vous devez prendre en charge mais que vous souhaitez ajouter REST pour atteindre plus de clients.
Référence
L'extrait suivant trouvé sur cette page MSDN résume bien ce dilemme.
Utilisez WCF pour créer des services Web fiables et sécurisés, accessibles sur différents types de transport. Utilisez l’API Web ASP.NET pour créer des services HTTP accessibles à partir d’un large éventail de clients. Utilisez l'API Web ASP.NET si vous créez et concevez de nouveaux services de style REST. Bien que WCF prenne en charge certaines tâches d'écriture pour les services de style REST, la prise en charge de REST dans l'API Web ASP.NET est plus complète et toutes les futures améliorations de fonctionnalités REST seront apportées à l'API Web ASP.NET . Si vous avez un service WCF existant et que vous souhaitez exposer des points de terminaison REST supplémentaires, utilisez WCF et WebHttpBinding.
Voici un bon article sur Web Service, WCF et Web API http://goo.gl/T29A5B
Service Web
- Basé sur SOAP et renvoyer des données XML
- Supporte uniquement le protocole HTTP. Il ne supporte que le protocole HTTP.
- Consommé par le client capable de comprendre les services xml SOAP.
- Peut héberger sur IIS. Il ne peut être hébergé que sur IIS.
- Facile à apprendre et à comprendre.
WCF
- Basé sur SOAP et renvoyer des données XML. SOAP est lourd comparez alors JSON et son overhead sur le réseau également.
- La version améliorée des services Web prend en charge plusieurs protocoles tels que TCP, HTTP, HTTPS, Named Pipes, MSMQ via configuration.
- Plus fiable lorsque le client et le serveur ont .Net.
- Sa mise en oeuvre et sa configuration est complexe
- Consommé par le client capable de comprendre les services xml SOAP.
- Auto-hébergement, IIS et utilisation des services Windows.
API Web (API Web 2.0)
- Conçu spécifiquement pour la création de services HTTP reposants sur .Net Framework.
- API Web facilement lisible et pratique en JSON.
- Prend en charge toutes les fonctionnalités de HTTP comme les URL, les requêtes/réponses, les en-têtes, la mise en cache et les versions.
- Les API Web prennent en charge de nombreux verbes HTTP tels que GET, POST, PUT, DELETE, etc.
- L'API Web est sans état.
- L'API Web prend en charge les fonctionnalités MVC (contrôleurs, résultats d'action, routage, filtre, classeurs de modèle, conteneur IOC ou injection de dépendance).
- Les API Web peuvent être auto-hébergées, hébergées dans l'application et sur IIS.
- OWIN (Interface Web ouverte pour .NET) est utilisé pour l’auto-hébergement.
L'API Web ASP.net est légère et le support de REST est intégré. Il est plus adapté aux applications mobiles. WCF est surchargé d’options. Cela dépend de la complexité du système pour en sélectionner un.