API Web WCF vs ASP .Net

93

Quels sont les avantages et les inconvénients de l'utilisation de chaque technologie?

WCF Web Api est maintenant fusionné dans Asp.net Asp.net Web Api prend désormais en charge l'auto-hébergement.

J'imagine toujours que si je veux exposer plusieurs schémas de protocole pour la même opération, je me pencherais toujours vers WCF ou le point final Mvc peut-il le faire aussi?

La nouvelle API Web Asp.Net expose-t-elle également Wsdl? Sinon, comment le client pourrait-il déterminer quelle opération est à sa disposition?

La meilleure caractéristique de Mvc est sans doute le modelbinder. Quelle est la robustesse de l'équivalent WCF?

Quelqu'un peut-il donc me dire quel avantage l'API Web Asp.net apporte-t-elle à la table? WCF semble le choix le plus puissant / évolutif, imo. La seule chose que l'API Web Mvc a sur le modèle WCF est probablement la facilité de développement, mais cela signifie s'accroupir si cela finit par être une limitation de conception sérieuse sur la route.

wcf asp.net-mvc-4 asp.net-web-api Alwyn
la source
15
Je trouve le titre de cette question un peu trompeur. Le titre est «MVC 4 vs API Web Wcf», mais la question semble concerner davantage l'API Web WCF vs ASP .Net. D'après le titre, je pensais que ce qui était comparé était le cadre standard MVC 4 (contrôleurs, modèles, vues) par rapport au cadre d'API Web ASP .Net. Quelqu'un d'autre trouve ce titre trompeur?
BruceHill le

Réponses:

72

Tout d'abord, je vous suggère de lire mon article sur le sujet: http://blogs.microsoft.co.il/blogs/idof/archive/2012/03/05/wcf-or-asp-net-web-apis-my- deux cents sur le sujet.aspx

En ce qui concerne votre question WSDL - puisque WebApi n'utilise pas SOAP, il ne nécessite pas de WSDL et n'en exporte pas. Vous pouvez utiliser Hypermedia pour renvoyer des ressources avec une liste d'URL d'activité possibles (considérez-le comme une ressource auto-descriptive)

IdoFlatow
la source
6
C'est une très très bonne rédaction. Le meilleur que j'aie jamais vu. Mais je suis maintenant plus confus que jamais. WebApi ajoute beaucoup, mais l'incapacité d'exposer d'autres points de terminaison semble très restrictive. Si vous aviez un client qui pouvait utiliser soap, il sera maintenant obligé de créer l'action et d'analyser le résultat à la main alors que soap aurait pu générer tout le contexte pour eux. Vous allez également les verrouiller hors de la fonction Soap plus avancée telle que la session fiable et la transaction Acid ...
Alwyn
2
@Alwyn - Je pense que tous les faits que vous avez mentionnés sont vrais et ne devraient donc pas vous dérouter mais plutôt vous aider à prendre une décision - L'API Web a ses propres avantages, mais si votre service doit être exposé à partir de plusieurs points de terminaison, y compris d'autres protocoles, ou vous avez un fort besoin de la fonction de génération automatique du client ou des fonctionnalités avancées de soap - cela pourrait expliquer pourquoi préférer WCF à l'API Web
BornToCode
@BornToCode: le code client peut être généré automatiquement avec WebAPI. Vous pouvez produire un fichier json swagger en utilisant le code WebAPI. Ce fichier json peut ensuite être utilisé par un générateur de code tel que swagger-codegen pour produire du code client dans un grand nombre de langues cibles.
laissé vide involontairement le
@unintentionallyleftblank - IMHO Il est toujours plus «convivial» de générer automatiquement le code client via WCF que l'API Web.
BornToCode
15

Le choix dépend de ce que nous voulons faire.

  1. L'API Web ASP.NET est une infrastructure pour créer des services non basés sur SOAP sur HTTP uniquement - il n'y a donc pas plus de protocoles de transport disponibles à l'aide de cette infrastructure.
  2. WCF / Windows Communication Foundation est un framework pour l'échange de messages SOAP - ici nous utilisons beaucoup de protocoles de transport: HTTP, TCP, canaux nommés, MSMQ, etc ...

Je ne suis pas sûr de savoir lequel a de meilleures performances en ce qui concerne la quantité de données, peut-être WCF puisque nous pouvons utiliser des protocoles bas. Tous les commentaires sont appréciés.

Junior Mayhé
la source
2
Aucune infraction, mais HTTP n'est qu'un protocole de couche application. Il n'a aucune restriction inhérente sur les protocoles de couche transport qui peuvent être utilisés.
smwikipedia
8

L'API Web WCF se concentre principalement sur les implémentations REST. Si vous configurez une implémentation REST, les bits WCF standard sont un peu pénibles à l'arrière. Si vous configurez des services RESTful, vous trouverez que l'API Web WCF est une expérience beaucoup plus agréable. Si vous configurez des services SOAP, l'API Web WCF n'est pas votre meilleur ami et vous feriez mieux d'utiliser WCF pour vos services.

Gregory A Beamer
la source
2
Oui, les configs sont pénibles, mais c'est un coût d'installation unique. Une fois que vous l'avez fait, vous pouvez pratiquement copier et coller le comportement / le point de terminaison dans un autre service. La plupart du temps, vous obtenez simplement en balisant les nouvelles opérations avec WebGet. D'un autre côté, si jamais vous obtenez un client qui souhaite utiliser Soap + Wsdl, ce n'est qu'un changement de configuration par opposition à code + deploy + QA + le reste. Alors, comment Mvc Web Api est-il meilleur?
Alwyn
1
Si vous êtes déjà à l'aise avec WCF, vous pouvez continuer sur cette voie. Il y a, en plus de ce que j'ai mentionné, des améliorations internes sur REST dans l'API Web WCF (je n'ai pas la liste devant moi), mais l'une ou l'autre peut fonctionner et je ne passerais pas des semaines à refactoriser si vous avez des tonnes de services de travail, esp. car il y a un changement de paradigme dans la pensée. Pour les travaux futurs, je considérerais cependant l'API Web WCF. Mais je suis avec l'API Web WCF depuis un certain temps, donc je suis peut-être partial.
Gregory A Beamer
0

Utilisez WCF pour les sites intranet / B2B n API Web pour les sites B2C / C2C / internet ... SOAP / XML est toujours le standard pour la communication intra-entreprise n ça ne va pas disparaître !!!

A_Var
la source