API Web WCF vs ASP.NET
J'ai passé quelques mois à essayer de comprendre les concepts de la WCF et j'ai récemment développé ma première application de service WCF.
J'ai eu beaucoup de mal à comprendre tous les paramètres du fichier de configuration.
Je ne suis pas convaincu par l'environnement, mais il semble que vous puissiez faire des choses incroyables avec cet environnement.
L'autre jour, j'ai découvert que Microsoft avait mis au point une nouvelle fonctionnalité appelée API Web ASP.NET.
Pour ce que je peux lire, c’est un framework RESTful, très facile à utiliser et à mettre en oeuvre.
Maintenant, j'essaie de comprendre quelles sont les principales différences entre les 2 frameworks et si je devais essayer de convertir mon ancien application de service WCF avec le nouveau API.
Est-ce que quelqu'un pourrait m'aider à comprendre les différences et les usages de chacun?
Le nouveau API Web ASP.NET est la continuation du projet précédent API Web WCF (bien que certains des les concepts aient changé ).
WCF a été créé à l'origine pour activer les services basés sur SOAP. Pour des services RESTful ou RPCish plus simples (pensez aux clients comme jQuery), l’API Web ASP.NET devrait être un bon choix.
Pour nous, WCF est utilisé pour SOAP et Web API for REST. Je souhaite que l'API Web soit prise en charge SOAP. Nous n'utilisons pas les fonctionnalités avancées de WCF. Voici la comparaison de MSDN :
L'API Web ASP.net est entièrement axée sur HTTP et sur le REST basé sur GET, POST, PUT, DELETE avec un style de programmation bien connu ASP.net MVC et retournable JSON; L'API Web s'adresse à tous les processus légers et aux composants purement basés sur HTTP. Pour aller de l'avant avec WCF, même pour un service Web simple ou simple, il apportera tous les bagages supplémentaires. Pour un service simple et léger pour les appels ajax ou dynamiques, WebApi répond toujours à vos besoins. Cela complète parfaitement ou aide en parallèle à ASP.net MVC.
Regardez le podcast: Hanselminutes Podcast 264 - Ce n'est pas la WCF de votre père - Tout sur le WebAPI avec Glenn Block par Scott Hanselman pour plus d'informations.
Dans les scénarios énumérés ci-dessous, vous devriez choisir WCF:
- Si vous devez envoyer des données sur des protocoles tels que TCP, MSMQ ou MIME
- Si le client consommateur sait simplement comment utiliser les messages SOAP
L'API WEB est une structure permettant de développer des services RESTful/HTTP.
Il y a tellement de clients qui ne comprennent pas SOAP comme Navigateurs, HTML5, dans ce cas, les API Web sont un bon choix.
En-tête de services HTTP spécifie comment sécuriser le service, comment mettre en cache les informations, le type du corps du message et le corps HTTP peut spécifier tout type de contenu tel que HTML, pas uniquement XML en tant que services SOAP.
Depuis que j'ai utilisé les deux jusqu'à maintenant, j'ai trouvé beaucoup de différences entre WCF et Web API. Les deux technologies se marient bien dans des scénarios différents. Il n’est donc pas possible de dire lequel est le mieux, cela dépend de la configuration et du scénario.
Remarque: les données ne sont pas seulement à mon avis, elles sont également collectées à partir d'un autre site officiel.
WCF vous donnera tellement de choses à faire, ce n'est même pas comparable. Sauf si vous souhaitez effectuer vous-même votre propre implémentation d'authentification, d'autorisation, de cryptage, de mise en file d'attente, de limitation, de messagerie fiable, de journalisation, de sessions, etc. WCF n'est pas [seulement] des services Web; WCF est une plate-forme de développement pour la SOA.
Il existe une comparaison sur MSDN à ce sujet
Pour moi, le choix portait sur Qui sont les clients et où sont-ils situés?
Au sein de la société Clients réseau et .NET: Utilisez WCF avec TCP binding (communication rapide par rapport à HTTP)
En dehors du réseau de l'entreprise et utilisez diverses technologies telles que PHP, Python etc : utilisez l'API Web avec REST.
Pourquoi je réponds:
J'ai pris énormément de temps pour comprendre la différence entre ces deux technologies. Je vais mettre tous ces points ici que je pense "Si j'avais ces points au moment où je me demandais à la recherche de cette réponse, alors j'ai décidé très tôt de choisir ma technologie requise."
Source d'information:
Microsoft® Visual Studio® 2015 Unleashed
ISBN-13: 978-0-672-33736-9 ISBN-10: 0-672-33736-3
Pourquoi API Web ASP.NET et WCF:
Avant de comparer les technologies des API Web ASP.NET et WCF, il est important de comprendre qu’il existe deux styles/normes pour la création de services Web: REST (Representational State Transfer) et SOAP/WSDL. SOAP/WSDL était la norme d'origine sur laquelle les services Web étaient construits. Cependant, il était difficile à utiliser et comportait des formats de messages volumineux (comme XML) qui dégradaient les performances. Les services basés sur REST sont rapidement devenus une alternative. Ils sont plus faciles à écrire car ils exploitent les constructions de base de HTTP (GET, POST, PUT, DELETE) et utilisent généralement des formats de message plus petits (comme JSON). En conséquence, les services HTTP basés sur REST sont désormais la norme pour les services d’écriture qui ciblent strictement le Web.
Définissons le but de l'API Web ASP.NET
L'API Web ASP.NET est la technologie de Microsoft permettant de développer des services Web HTTP basés sur REST. (Elle remplaçait depuis longtemps ASMX de Microsoft, basé sur SOAP/WSDL.) L’API Web facilite l’écriture de services robustes basés sur des protocoles HTTP que tous les navigateurs et périphériques natifs comprennent. Cela vous permet de créer des services pour prendre en charge votre application et de les appeler à partir d'autres applications Web, tablettes, téléphones mobiles, ordinateurs et consoles de jeux. La majorité des applications écrites aujourd'hui pour tirer parti de la connexion Web toujours présente utilisent les services HTTP d'une manière ou d'une autre.
Définissons maintenant le but de la WCF:
Communiquer sur Internet n'est pas toujours le moyen le plus efficace. Par exemple, si le client et le service reposent sur la même technologie (ou même sur le même ordinateur), ils peuvent souvent négocier un moyen de communication plus efficace (tel que TCP/IP). Les développeurs de services ont été amenés à faire les mêmes choix qu’ils essayaient d’éviter. Il leur faudrait maintenant choisir entre la création de services internes efficaces et la possibilité de bénéficier du large accès trouvé sur Internet. Et, s'ils devaient prendre en charge les deux, ils pourraient être amenés à créer plusieurs versions de leur service ou au moins des mandataires séparés pour accéder à leur service. C'est le problème que Microsoft a résolu avec WCF .
Avec WCF, vous pouvez créer votre service sans se soucier des limites. Vous pouvez ensuite laisser la WCF s’inquiéter de l’exécution de votre service de la manière la plus efficace, en fonction du client appelant. Pour gérer cette tâche, WCF utilise le concept de points de terminaison. Votre service peut avoir plusieurs noeuds finaux (configurés au moment de la conception ou après le déploiement). Chaque terminal indique comment le service peut prendre en charge un client appelant: sur le Web, via la communication à distance, via Microsoft Message Queuing (MSMQ), etc. WCF vous permet de vous concentrer sur la création de la fonctionnalité de votre service. Il s'inquiète de la façon de parler le plus efficacement possible avec les clients appelants. De cette manière, un seul service WCF peut efficacement prendre en charge de nombreux types de clients.
Exemple de WCF:
Considérons l'exemple:
Les données client sont partagées entre les applications. Chaque application peut être écrite sur une plate-forme différente et peut exister à un emplacement différent. Vous pouvez extraire l'interface client dans un service WCF offrant un accès commun aux données client partagées. Cela centralise les données, réduit les doublons, élimine la synchronisation et simplifie la gestion. De plus, en utilisant WCF, vous pouvez configurer les points de terminaison de service de manière à ce qu'ils aient un sens pour le client appelant. La figure montre l'exemple précédent avec un accès centralisé aux données client dans un service WCF.
Conclusion:
i) Quand choisir l'API Web:
On ne peut nier que les services HTTP basés sur REST, tels que ceux créés à l'aide de l'API Web ASP.NET, sont devenus la norme pour la création de services Web. Ces services offrent une approche simple et directe pour les services de développement de développeurs Web. Les développeurs Web comprennent HTTP GET et POST et s'adaptent donc bien à ces types de services. Par conséquent, si vous écrivez des services strictement destinés à HTTP, L'API Web ASP.NET est le choix logique.
ii) Quand choisir WCF:
La technologie WCF est utile lorsque vous devez prendre en charge plusieurs points de terminaison de service basés sur différents protocoles et formats de message. Des produits tels que Microsoft BizTalk exploitent WCF pour créer des services robustes pouvant être utilisés sur le Web ainsi que via différentes configurations ordinateur à ordinateur. Toutefois, si vous devez écrire une application qui communique via TCP/IP lorsqu’il est connecté au réseau local et fonctionne sous HTTP en dehors du réseau, WCF est votre réponse .
Être averti:
Les développeurs Web considèrent souvent que WCF est plus difficile et complexe à développer. Par conséquent, si vous ne prévoyez pas le besoin de services multiprotocoles, vous vous en tiendriez probablement à l'API Web ASP.NET.
En tant que professionnel, WebApi ne possède pas de WSDL, les développeurs doivent donc tout documenter manuellement. Et si, par exemple, l’opération WebApi renvoie une liste d’objets, le client doit les créer manuellement, c’est-à-dire que WebAPI est réellement sujet aux erreurs de définitions.
Le pro de Webapi est son plus léger que WCF.
En ce qui concerne la déclaration "WebApi manque de WSDL", il existe plusieurs façons de générer un client Rest. Une approche populaire est Swagger UI/(Swashbukkle Nuget). Cela donne une interface riche pour comprendre le schéma d'entrée et de sortie du noeud final REST et l'outil en ligne pour tester les noeuds finaux.
JSON LD (Json Linked Documents) est un autre standard émergent qui améliorera encore l'expérience du développeur REST basé sur JSON en exposant le schéma JSON avec une meilleure sémantique.
Avec wcf, nous pouvons configurer et exposer le même service de support pour plusieurs systèmes d'extrémité tels que tcp, http.si vous voulez que votre service soit uniquement basé sur http, il sera préférable d'utiliser l'API Web. L'API Web a très peu de configuration par rapport à wcf et est un peu plus rapide que wcf. Wcf prend également en charge des services reposants. Si vous avez une limitation de .Net Framework 3.5, votre option est wcf.