Quelle est la différence entre WCF Web API et ASP.NET accueil

D'après ce que J'ai appris, Microsoft a fait un peu de confusion de nommage ici.

Je suppose que vous savez ce qu'est WCF, ce grand framework construit au-dessus de XML pour permettre à L'utilisateur de construire des services distribués avec une grande variété de technologies (de SOAP à REST à MSMQ etc.).

C'est dur à utiliser (pour moi au moins) et nécessite beaucoup de bootstrap pour le faire fonctionner, et finalement ils ont réalisé cela et ont commencé à fournir une configuration par défaut pour http simple services (WCF REST starter kit quelqu'un?). ASP.NET MVC prenait de l'ampleur et certaines des fonctionnalités qu'il fournissait (correspondance automatique des arguments par exemple) ont commencé à apparaître dans WCF.

Maintenant, c'est la situation:

Annonce: WCF Web API est maintenant ASP.NET accueil ASP.NET Web API publié avec ASP.NET MVC 4 Bêta. L'API Web WCF et le support WCF pour le contenu de jQuery sur ce site sera supprimé à 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 sûr qu'il devrait être possible d'héberger asp.net MVC4 webapi au-dessus de WCF (si vous en avez besoin), mais je ne trouve pas de documentation qui peut me prouver le bien (ou le mal).

Mise à jour (ne peut pas tenir comme commentaire): Attendez, il y a un énorme différent entre " déplacer un sous-ensemble de la technologie de communication d'un bibliothèque / cadre à un autre " et "remplacer 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 passe quelque peu à de nouvelles solutions (et plus simples) (regardez le SOAP riche en fonctionnalités vs Le Lean e flexible REST, bien que beaucoup de gens utilisent encore REST de manière RPC), et je pense que ce genre de modèles de programmation s'intègre mieux dans l'architecture MVC que celle de WCF. Des efforts ont été mis sur la conception de certains 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 maintenant ASP.NET MVC et que vous voulez faire des services web rest pour leur application web, jouer avec WCF est souvent exagéré pour ce genre de choses, et j'ai vécu cela sur ma propre peau.

Je pense que le mécanisme de routage est génial et la bonne façon d'aller, et si vous regardez de près, ils en ont inclus une partie (avec différents noms et types, mais le modèle était là) dans WCF. Donc oui, je pense que si MS ne rejette pas cette partie de WCF NOUS devrions le faire. Pour répondre strictement, Non, Je ne pense pas que vous trouverez jamais WebGet / WebInvoke dans asp.net mvc*, il ne rentre tout simplement pas dans.

Ouais self-host est probablement le seul bit de WCF contenu dans ASP.NET MVC4 maintenant.

On dirait que WCF lui-même est en train de mourir ou du moins de devenir beaucoup moins important alors qu'il était censé être et à cause de cela, il a aussi beaucoup moins d'effort de développement mis dans son ensemble de fonctionnalités. Les nouvelles fonctionnalités de WCF elles-mêmes sont plus cosmétiques.

WCF a été conçu comme moyen indépendant du transport / protocole pour la communication inter-processus. Même l'idée était une abstraction indépendante, elle était principalement construite au-dessus de la pile SOAP. Lorsque WCF 3.5 a apporté un support pour REST c'était surtout piraté parce que REST est tout au sujet de la dépendance au transport. L'utilisation de L'API indépendante du transport pour prendre en charge la communication inter-processus qui se fait directement à l'aide des fonctionnalités de transport est apparue gênante. En conséquence, MS a d'abord publié WCF REST API Starter Kit qui n'a jamais atteint RTM, mais il était aperçu des fonctionnalités qui a ensuite été inclus dans WCF 4 et enfin dans.Net 4.5 ou WCF Web API. Parce que REST est dépendant du transport et actuellement utilisé uniquement avec HTTP (même s'il est théoriquement possible de utiliser un autre protocole de transport) L'API a été déplacée vers la partie. net qui est plus appropriée pour le traitement HTTP-à actuellement très populaire ASP.NET MVC.

L'API Web WCF est remplacée par ASP.NET API Web qui prend des fonctionnalités de L'API Web WCF et les fusionne avec les fonctionnalités D'ASPNet MVC. ASP.NET L'API Web est un nouveau framework (02/2012) pour la création et la consommation de services HTTP et une plate-forme pour la création de services RESTful.

Bien que pas dans la question originale, il semble intéressant de noter que WCF est bien vivant et son support REST reste utile lorsque vous avez des services SOAP (WS-*) existants que vous devez supporter mais que vous voulez ajouter REST pour atteindre plus de clients.

Référence

1. Bienvenue sur ASP.NET API Web
2. CodePlex: Daniel Roth sur L'avenir de WCF
3. Chanel9: Dan Roth sur le nouveau ASP.NET API Web

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 une variété de transports. Utilisation ASP.NET API Web pour créer des services HTTP accessibles à partir d'une grande variété de clients. Utilisation ASP.NET API Web si vous créez et concevez de nouveaux services de style REST. Bien que WCF fournisse un support pour l'écriture de services de style REST, le support pour REST dans ASP.NET L'API Web est plus complète et toutes les futures améliorations des fonctionnalités REST seront apportées en ASP.NET API Web. 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 le Service Web, WCF et Web API http://goo.gl/T29A5B

Service Web

• basé sur SOAP et renvoie des données XML
• supporte uniquement le protocole HTTP. Il supporte uniquement le protocole HTTP.
• consommé par le client capable de comprendre les Services SOAP xml.
• peut héberger sur IIS. Il peut être hébergé uniquement sur IIS.
• facile à apprendre et à comprendre.

WCF

• basé sur SOAP et return XML Données. SOAP est lourd comparer alors JSON et ses frais généraux sur le réseau aussi.
• la version améliorée des services web prend en charge plusieurs protocoles tels que TCP, HTTP, HTTPS, Named Pipes, MSMQ via la configuration.
• plus fiable lorsque le client et le serveur ont .Net.
• son implémentation et sa configuration sont complexes
• consommé par le client capable de comprendre les Services SOAP xml.
• auto-hébergement, IIS et utilisation des services windows.

Accueil API 2.0)

• conception spécifique pour la construction de services HTTP Restful sur. NET Framework.
• API Web facilement lisible et pratique comme JSON.
• prend en charge toutes les fonctionnalités de HTTP telles que les URL, les requêtes/réponses, les en-têtes, la mise en cache et la gestion des versions.
• L'API Web prend 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èles, conteneur IOC ou injection de dépendance)
• L'API Web peut être auto-hébergée, hébergée avec dans L'application et sur IIS.
• OWIN (Open Web Interface for. NET) est utilisé pour l'auto-hébergement.

ASP.net l'api web est légère et le support REST intégré. Il est plus approprié pour les applications mobiles.WCF est gonflé avec plus d'options . Il dépend de la complexité du système pour sélectionner l'un de ces.