Comment gérer le débat technique entre WCF et Web API?

Je gère actuellement une équipe de 15 développeurs environ, et nous sommes bien arrêtés au moment de choisir la technologie. L'équipe est divisée en deux équipes complètement opposées, débattant de l'utilisation de WCF par rapport à l'API Web.

L’équipe A, qui prend en charge l’utilisation de l’API Web, avance les raisons suivantes:

1. L'API Web n'est que la manière moderne d'écrire des services ( Wikipedia )
2. WCF est une surcharge pour HTTP. C'est une solution pour TCP, Net Pipes et autres protocoles
3. Les modèles WCF ne sont pas POCO, à cause de [DataContract] & [DataMember] et de ces attributs
4. SOAP n'est pas aussi lisible et pratique que JSON
5. SOAP est une surcharge pour le réseau comparé à JSON (transport sur HTTP)
6. Aucune méthode surchargée

L’équipe B, qui prend en charge l’utilisation de WCF, déclare:

1. WCF prend en charge plusieurs protocoles (via la configuration)
2. WCF prend en charge les transactions distribuées
3. Il existe de nombreux bons exemples et exemples de réussite pour la WCF (alors que l'API Web est encore jeune)
4. Le duplex est excellent pour la communication bidirectionnelle

Ce débat se poursuit et je ne sais pas quoi faire maintenant. Personnellement, je pense que nous devrions utiliser un outil uniquement pour son bon lieu d'utilisation . En d'autres termes, nous devrions utiliser les API Web si nous voulons exposer un service via HTTP, mais utiliser WCF pour TCP et Duplex.

En cherchant sur Internet, nous ne pouvons pas obtenir un résultat solide. Il existe de nombreux postes de soutien à la WCF, mais au contraire, on constate également des plaintes de personnes. Je sais que la nature de cette question peut sembler discutable, mais nous avons besoin de bons indices pour décider. Nous sommes bloqués à un moment où le choix d'une technologie par hasard pourrait nous faire regretter celle-ci plus tard. Nous voulons choisir les yeux ouverts.

Notre utilisation serait principalement pour le Web et nous exposerions nos services via HTTP. Dans certains cas (disons 5 à 10%), nous pourrions toutefois avoir besoin de transactions distribuées.

Qu'est-ce que je devrais faire maintenant? Comment gérer ce débat de manière constructive?

Lorsque les deux côtés ont de bons arguments et que les opinions sur la question sont trop fortes pour parvenir à un consensus, vous devez, en tant que responsable, prendre une décision et mettre fin au débat. Sinon, il ne fera que tourner en rond et renforcer encore plus les positions de tous les participants. Plus vous attendez, plus il sera difficile pour le "perdant" d'admettre sa défaite et de travailler de manière productive avec le résultat.

Ecrivez tous les arguments, valorisez leur importance pour le projet, puis prenez votre décision. Lorsque vous ne pouvez pas, lancez une pièce de monnaie. Votre projet peut probablement être mené à bien avec l'une ou l'autre des technologies, et perdre du temps précieux en discussions inutiles ne vous coûtera que de l'argent inutile.

En supposant que les deux côtés soient 100% corrects dans tous leurs arguments, lesquels sont importants?

Les modèles WCF ne sont pas POCO, à cause de [DataContract] & [DataMember] et de ces attributs

Ça t'intéresse? Envisagez-vous de faire quelque chose qui nécessite POCO?

WCF prend en charge les transactions distribuées

Encore une fois, est-ce quelque chose que vous allez utiliser et que vous devez construire si vous ne l'avez pas parce que vous avez emprunté l'autre voie?

Fondamentalement au cœur de laquelle:

• Offre tout ce dont vous avez besoin (si ni l’une ni l’autre n’offre tout ce dont vous avez besoin, vous devez faire le moins de travail possible).
• Offre le moins de déchets que vous n'allez pas utiliser mais que vous devez supporter de toute façon.

Tout argument avancé qui ne va pas dans le sens de ce que vous devez accomplir est sans importance et ne devrait pas entrer en ligne de compte dans votre décision, avec une certaine marge de manœuvre pour envisager une expansion future.

Mettez mes deux sous

En tant que manager, vous devriez demander à vos coéquipiers de garder à l’esprit le principe de Yagni . Cela aidera à réduire la liste des raisons avancées par les deux équipes.

Notre utilisation serait principalement pour le Web et nous exposerions nos services via HTTP. Dans certains cas (disons 5 à 10%), nous pourrions toutefois avoir besoin de transactions distribuées.

Plutôt que de plonger dans une transaction distribuée, envisagez plutôt de travailler avec une rémunération .

La dernière chose à prendre en compte est la courbe d'apprentissage. En fonction de la date limite de votre projet, en tant que responsable, vous devriez être en mesure de décider s’il convient de commencer ou non à apprendre une nouvelle technologie.

Si vous avez beaucoup de temps à perdre, optez pour une sorte de Journée de l' innovation au cours de laquelle les équipes A et B disposeraient d'une journée pour produire une preuve de concepts basée sur les mêmes exigences.

En passant, au type qui dit "les modèles WCF ne sont pas POCO, à cause de [DataContract] & [DataMember] et de ces attributs ", dites-lui que les POCO sont généralement destinés à être des entités de domaine et que ce n'est pas une meilleure pratique d'exposer votre objet de domaine à n’importe quel type de client, c’est ce à quoi servent les DTO.

Qu'est-ce que je devrais faire maintenant? Comment gérer ce débat de manière constructive?

D'abord, éloignez la subjectivité. Dans votre argumentation de l' équipe de WebAPI, je trouve « API Web est juste la façon moderne » *, « modèles WCF ne sont pas POCO, à cause de ces attributs » et « SOAP n'est pas aussi lisible et maniable comme JSON » assez opiniâtres, si tort de ne pas ordinaire et ne vous aidera pas à prendre une décision.

Alors, que faire: décidez ce que vous voulez faire avec votre / vos service (s) , puis choisissez une technique qui tienne compte de cet objectif, ainsi que sa facilité de maintenance et son extensibilité avec le moins de douleur possible. Vous pouvez le faire en recherchant simplement si un aspect donné est pris en charge par le cadre à utiliser.

Matériel de lecture intéressant:

• Mvc 4 vs Wcf Web Api
• API Web WCF ou ASP.NET? Mes deux cents sur le sujet
• WebAPI ou WCF?

*: notez que vous vous référez à Wikipedia, où la citation est: " Les applications Web Web 2.0 se sont éloignées d'une architecture orientée services (SOA) avec des services Web basés sur SOAP vers des collections plus cohérentes de ressources Web RESTful" . C'est un exemple d'utilisation lorsque votre service doit être utilisé à partir d'une page Web. Cela peut aussi être facilement fait avec WCF, en utilisant WebHttpBinding. Il ne dit pas "Utilisez WebAPI pour cela" .

Si cette question dépasse le cadre "comment gérer la discussion" : j'utiliserais WCF si les services doivent être consommés par des non-clients Web, car ses métadonnées permettent une génération de clients fortement typée étonnamment facile.

En dehors de la gestion d’équipe, vous ne choisissez pas l’une sur l’autre. Vous devez examiner le but de chaque service Web et utiliser la technologie appropriée pour la partie spécifique de l'application. C'est comme interdire les procédures de magasin lorsque l'équipe utilise un cadre d'entité.

Notre utilisation serait principalement pour le Web et nous exposerions nos services via HTTP. Dans certains cas (disons 5 à 10%), nous pourrions toutefois avoir besoin de transactions distribuées.

Ensuite, vous écrivez ces 5 à 10% de services Web dans la WCF. Si le service doit être référencé en interne dans d'autres projets, il n'y a pas de débat. L’avantage de pouvoir importer un contrat WCF pour créer le proxy client n’est PAS ouvert à la discussion. L'intégration, l'efficacité et la sécurité des types sont poussées à un tout autre niveau.

Vous écrivez ce qui doit être utilisé pour les requêtes api publiques (peut-être) / Ajax dans l'API web Asp.net.

S'il s'agit simplement d'un appel ajax spécifique à une page, vous pouvez simplement utiliser Asp.Net MVC.

Ne choisissez pas, embrasse-les tous. WCF et Asp.net web api servent différents objectifs. Personne ne dit que vous ne pouvez pas avoir de pomme et d'orange dans votre salade de fruits. Essayer de choisir l’un sur l’autre et de l’abattre dans tous les scénarios n’est que pure paresse.

Notre équipe a eu une discussion similaire il y a quelques mois. Pour nous, le facteur décisif dépendait de la manière dont nous créerions et mettrions en œuvre chaque technologie. Comme nous étions déjà en train de créer une application MVC et que nous utilisions Knockout.js pour la liaison de données, nous utilisions efficacement MVVM, les contrôleurs n'étant qu'un API pour les données.

Cela nous a permis de classer notre utilisation des technologies avec ce projet comme suit:

• La Web API serait utilisée comme notre API pour les appels masqués et Ajax, ce qui en ferait nos commandes pour le modèle MVVM. Notre logique métier pour l'application Web repose sur cette couche grâce à un certain nombre de classes, de référentiels et d'usines.
• WCF est ensuite utilisé pour notre magasin de données, exposant les données de notre base de données non seulement pour ce site Web, mais également pour tout autre site ou service ayant utilisé les données exposées.

Bien que cela ne soit pas une réponse populaire ou hyper technique, déterminer ce dont vous avez besoin en premier lieu et comment ou si la technologie aidera, est ce qui a aidé mon équipe à décider quelle technologie utiliser où.

En d'autres termes, nous devrions utiliser les API Web si nous voulons exposer un service via HTTP, mais utiliser WCF pour TCP et Duplex.

Ce serait l'approche la plus raisonnable. Il est assez courant de disposer des services WCF et WebApi dans la même application Web, où les deux servent des objectifs différents.

Juste pour corriger quelques arguments:

Les modèles WCF ne sont pas POCO, à cause de [DataContract] & [DataMember] et de ces attributs

Dans de nombreux cas, les modèles WCF fonctionnent sans attributs datacontract / datamember.

SOAP n'est pas aussi lisible et pratique que JSON

Ce n'est pas vrai, mais les services Web WCF utilisent généralement du XML simple plutôt que du SOAP saturé. Ce certainement est lisible.

Un argument pour WCF: si un WSDL est disponible, il existe des tonnes d'outils dans presque toutes les technologies qui peuvent créer des proxies à partir des métadonnées. D'autre part, le schéma JSON n'est pas encore largement pris en charge.

Pourquoi ne pas suivre la ligne avec WCF Data Services? De belles requêtes de style OData / webapi et une facilité d’utilisation avec les pouvoirs de WCF, ainsi que la possibilité de revenir JSONparfaitement. De plus, Wcf n’est pas si mauvais si vous avez un bon code d’hébergement wcf automatique comme celui-ci:

https://github.com/ImaginaryDevelopment/MvcOdata

Je dirais qu'ils ne sont pas du tout séparés, sauf que lorsque nous sommes allés utiliser WebApià l'avant et WCF data servicesau niveau intermédiaire, nous avons WebApiparlé de choses simples comme des chaînes contenant ou des opérateurs d'odata de correspondance de chaîne.

Un bon architecte retarde les décisions technologiques jusqu'à ce qu'elles soient absolument nécessaires.

En d'autres termes, ne prenez pas la décision tant qu'un client n'a pas réellement besoin de se connecter. Vous pouvez créer une couche de service entièrement testée sans y placer réellement un mécanisme de transport / communication. Plus de 95% du travail peut être effectué "sous" l'adaptateur, en dehors du cadre.

Le moment venu d’exposer ces services aux clients distants, vous pouvez choisir l’infrastructure la plus tendance du marché et écrire des enveloppes minces sur une couche de services polyvalente.

Bon sang, si votre "vraie" couche de service est bien faite, vous pouvez même essayer plusieurs wrappers à un coût minime.

C'est la réponse dogmatique, de toute façon. En pratique , vous pouvez choisir l' outil le plus simple disponible pour faciliter les tests d'intégration rapides et fréquents, tout en limitant votre dépendance et en le traitant strictement comme une simple couche de communication par rapport aux services réels .

Si vous adoptez cette approche, vous constaterez probablement que vous choisissez l'outil le plus simple à utiliser au départ et que personne ne s'en rendra compte , car l'équipe sait qu'elle peut mettre en œuvre ultérieurement un outil ou un cadre plus sophistiqué ou plus tendance, si nécessaire , avec un minimum d'effort.

Par conséquent, je suis maintenant confronté au même choix. Je me suis demandé quel était le sous - ensemble de fonctionnalités de la WCF que notre équipe utilise en ce moment. Utilisons-nous des protocoles différents? Est-ce que nous utilisons le support de transaction? Non (bien que nous utilisions des mécanismes de cohérence éventuels personnalisés). Utilisons-nous le duplex? Non.

Pourquoi voudrions-nous utiliser l'API Web? Intégration frontale simplifiée (suppression de la couche de service supplémentaire existante), SignalR pour l'envoi de réponses aux clients, mise en cache pour les GET.

Peut-être, on pourrait trouver d'autres raisons :) Ainsi, des raisons de rester avec WCF.

Si j'étais à votre place, je commencerais par examiner les capacités de vos équipes. Si tous les membres de votre équipe connaissent déjà la WCF et que seul un petit pourcentage connaît l'API Web, votre décision est déjà prise pour vous.

Si vous avez le temps, investissez-le dans l’apprentissage et l’amélioration de votre base de connaissances, mais pas au détriment des besoins de l’entreprise et de sa productivité.

Je voudrais demander quel modèle d'interaction avez-vous besoin de soutenir? Votre interface externe souhaitée ressemble-t-elle davantage à RPC ou à REST? D'après mon expérience, c'est généralement quelque part entre mais surtout l'un ou l'autre.

Utilisez-vous vos propres services pour d’autres projets en .Net? C’est probablement la question la plus révélatrice que vous puissiez poser. WCF a l'avantage de pouvoir résumer vos interfaces dans une bibliothèque de classes séparée et de pouvoir créer et injecter votre client. En guise d’extension, vous pouvez monter votre projet basé sur WCF avec les points de terminaison JSON et SOAP / WSDL. Je l’ai déjà fait. WCF offre également de meilleures assurances contre vos interfaces définies.

Cela dit, si vous vous attendez à avoir des clients d’autres plates-formes XML en général, encore moins SOAP a-t-il une surcharge mesurable qui dépasse celle des simples points de terminaison JSON. Si vous choisissez la route JSON / API Web, vous devrez mieux expliquer comment interagir avec vos points de terminaison et votre API.

En général, je suggérerais d'écrire un document d'API simple qui indique comment vous allez soumettre les données et comment vous voulez une réponse pour une structure d'objet de requête unique. Rédigez votre scénario de test de la manière la plus universelle et documentez-le en tant que tel. Je recommanderais une simple déclaration curl. Ensuite, plusieurs de vos membres l'implémentent à l'aide de WCF et de l'API Web. Ensuite, voir qui gagne.

Personnellement, malgré des projets et des mises en œuvre relativement importants avec WCF, je me tourne plutôt vers la mise en œuvre la plus simple, qui dans mon esprit est en réalité une WCF directe avec l'utilisation de résultats JSON et un comportement prioritaire dans Global.asax.cs pour traiter les conditions d'erreur. Si la documentation d'une API inclut des instructions curl et que vous pouvez exercer toutes les fonctionnalités de votre API avec des exemples de courbes, il est beaucoup plus facile pour les clients d'être implémentés dans n'importe quel langage prenant en charge les interfaces Web. C’est vraiment là que la WCF commence à tomber. Avoir une API bien définie avec une documentation agnostique est préférable à des structures avec des outils automatisés pour traiter avec des systèmes étrangers. Parler en tant que consommateur de ces systèmes depuis d'autres plateformes.

Au-delà de cela, implémentez votre client dans deux langues différentes. Faites un client en C #, mais aussi en Node.js ou en Python et voyez à quel point ils s’adaptent bien. Cet exercice à lui seul vous aidera à éviter les difficultés dans votre API.