API Web ASP.NET vs services de données WCF (OData)
Je conçois une application distribuée comprenant des services RESTful et divers clients (Silverlight, iOS, Windows Phone 7, etc.). Actuellement, je détermine quelle technologie utiliser pour implémenter mes services, les services de données WCF (OData) ou la nouvelle API Web ASP.NET fournie avec ASP.NET MVC 4.
J'ai visionné quelques présentations en ligne sur chacune d'elles et je me tourne maintenant vers WCF Data Services, principalement à cause des mécanismes de filtrage intégrés à l'URI et à la capacité hypermédia native. Le seul inconvénient que je puisse voir est la verbosité de la spécification Atom Pub par opposition à POX.
Y a-t-il quelque chose que je devrais savoir à propos de ces deux technologies avant de prendre une décision? Pourquoi quelqu'un choisirait-il l'API Web ASP.NET plutôt que les services de données WCF?
C'est une question subjective, alors voici une réponse subjective. OMI, WCF a beaucoup trop de frais généraux pour des services RESTful simples. L'API Web, en revanche, a été conçue spécifiquement pour les services RESTful.
Je suis d'accord avec Dave Ward à ce sujet . Consultez son blog pour plus d'informations.
J'ai longtemps résisté à la pression pour passer d'ASMX à WCF en Projets WebForms, car acceptant uniquement la complexité de la WCF m'a récompensé avec une sérialisation JSON moins flexible. En revanche, j’ai commencé à convertir certains de mes projets d'ASMX en API Web et ont été satisfait de la facilité avec laquelle l’API Web remplace ASMX.
Je crois que Microsoft a finalement trouvé un bon équilibre entre le simplicité et puissance de WCF avec Web API.
Il existe actuellement d'autres différences majeures entre WebApi et WCF Data Services, que personne ne semble jamais mentionner. J'aimerais que MS publie un bon article comparant les deux.
Cela fait un moment que je suis OData et WebApi. J'ai toujours trouvé quelques distinctions majeures.
Premièrement, je ne suis pas sûr de ce que votre patron entend par "MS soutient WebApi", cela signifie qu'ils ne soutiennent pas OData? OMI, ils soutiennent les deux et il y a actuellement un chevauchement minimal. Windows Azure Data Market expose leurs données à l'aide d'OData, Azure Table Storage utilise OData, SharePoint 2010 autorise les requêtes OData sur ses données et d'autres produits MS le prennent également en charge, comme Excel PowerPivot. C'est un framework de requête très puissant en matière de données relationnelles. Et comme il est RESTful, n’importe quel langage, cadre, appareil, etc. peut s’intégrer à celui-ci.
Voici ce que j'aime chez OData + WCF Data Services:
OData + WCF Data Services a enfin permis aux applications clientes d’être plus "expressives" lors de l’interrogation de données sur le Web. Auparavant, nous devions toujours utiliser ASMX ou WCF pour créer des API Web rigides qui devenaient trop lourdes et demandaient des modifications constantes chaque fois qu'une interface utilisateur souhaitait quelque chose de légèrement différent. L'application cliente pouvait uniquement spécifier des paramètres pour déterminer les critères à renvoyer. Ou faites comme je l'ai fait et "sérialisez" les expressions LINQ et transmettez-les en tant que paramètres et ré-hydratez-les dans Expressions<Func<T,bool>> sur le serveur. C'est décent. Le travail est fait, mais je souhaite utiliser LINQ sur le client et le faire traduire sur le Web à l'aide de REST, ce que permet exactement OData et je ne souhaite pas utiliser mon propre "bidouillage" de solution.
C'est comme si vous exposiez "TRANSACT SQL" sans avoir besoin d'une chaîne de connexion à la base de données. Fournissez simplement une URL et un whoala! Commencez à interroger. Bien sûr, WebApi et WCF Data Services prennent en charge l’authentification/autorisation. Vous pouvez donc contrôler l’accès, ajouter des instructions «Where» supplémentaires en fonction des rôles ou d’une autre configuration de données. Je préférerais le faire dans ma couche Web Api plutôt que dans SQL (comme la construction de vues ou de processus stockés). Et maintenant que les applications peuvent créer des requêtes elles-mêmes, vous verrez les outils de reporting ad-hoc et BI commencer à tirer parti d'OData et permettre aux utilisateurs de définir leurs propres résultats. Ne pas compter sur les rapports statiques où ils ont un contrôle minimal.
Lors du développement dans Silverlight, Windows 8 Metro ou ASP.NET (MVC, WebForms, etc.), vous pouvez simplement ajouter une "référence de service" dans Visual Studio au service de données WCF et commencer rapidement à utiliser LINQ pour interroger les données ET vous obtenez un message. "Contexte des données" sur le client, ce qui signifie qu'il suit les modifications et vous permet de "Soumettre" vos modifications de manière atomique au serveur. Ceci est très similaire aux services RIA pour Silverlight. J'aurais utilisé WCF Data Services au lieu de RIA Services, mais à l'époque, il ne supportait pas DataAnnotations ou Actions, mais maintenant :) Les services de données WCF présentent un autre avantage par rapport aux services RIA, à savoir la possibilité d'effectuer des "projections". du client. Cela peut aider à la performance, au cas où je ne veux pas renvoyer toutes les propriétés d'une entité. Avoir un "contexte de données" sur le client est idéal pour traiter avec des applications métier.
Ainsi, WCF Data Services est idéal si vous avez des données avec des relations, en particulier si vous utilisez SQL Server et Entity Framework. Vous serez rapidement en mesure d’exposer des données pouvant être interrogées + actions (appels à invoquer des opérations, c’est-à-dire des flux de travail, des processus en arrière-plan) via REST avec très peu de code. WCF Data Services vient d'être mis à jour. Nouvelle version lancée. Découvrez toutes les nouvelles fonctionnalités.
L’inconvénient de WCF Data Services est le "contrôle" que vous perdez sur la pile HTTP. J'ai trouvé le plus gros défaut dans les méthodes IQueryable<T> qui renvoient des collections. Contrairement aux services RIA ET WebApi, vous n’avez PAS un accès complet au développement de la logique dans la méthode IQueryable. Dans les services RIA et WebApi, vous pouvez écrire le code de votre choix à condition de renvoyer IQueryable<T>. Dans WCF Data Services, vous avez UNIQUEMENT accès à une déclaration "Où" à l'aide de méthodes d'interception Expression<Func<T,bool>>. J'ai trouvé cela décevant. Notre application actuelle utilise les services RIA et je constate que nous avons vraiment besoin de la capacité de contrôler la logique IQueryable. J'espère que je me trompe et qu'il me manque quelque chose
De plus, WCF Data Services ne prend pas non plus totalement en charge tous les opérateurs LINQ. Il supporte toujours plus que WebApi cependant.
Qu'en est-il de WebApi ???
- J'aime le contrôle de la requête/réponse HTTP
- Il est facile à suivre (en utilisant les modèles MVC). Je suis sûr que plus d'outillage viendra.À ce jour (à ma connaissance), il n’existe pas de support «Contexte de données» sur le client (c’est-à-dire Silverlight, Code côté serveur ASP.NET, etc.), car WebApi ne concerne pas vraiment les modèles de données Entity comme WCF Data Services/OData. est. Il peut exposer des collections d'objets de modèle à l'aide d'IQueryable/IEnumerable, mais il n'y a pas de "Propriétés de navigation" de clé primaire/clé étrangère (c.-à-d. Client.Invoices) à utiliser une fois les entités chargées sur le client, car il n'y a pas de "Contexte de données". qui les charge de manière asynchrone (ou dans un appel en utilisant $ expand), et gère les modifications. Vous n'avez aucune "représentation" générée par le code de votre modèle de données d'entité sur le client, comme dans les services RIA ou les services de données WCF. Je ne dis pas que vous ne pouvez pas/n'avez pas de modèles dans le client qui représentent vos données, mais vous avez rempli manuellement les données et géré quelles "factures" doivent être définies avec chaque "client" une fois qu'elles ont été extraites la toile. Cela peut être délicat, spécialement avec tout ce qui se passe en Async. Vous ne savez pas quels appels vont revenir en premier. Cela peut être difficile à expliquer ici, mais il suffit de lire des informations sur le "contexte de données" dans les services RIA ou WCF Data Services . Ainsi, lorsque je traite avec des applications métier, c’est un problème majeur pour moi. Ceci est principalement basé sur la productivité et la maintenabilité. Vous pouvez créer des applications de manière obsolète sans contexte de données. Cela facilite simplement les choses, spécialement dans Silverlight, WPF et maintenant Windows 8 Metro. Avoir des entités relationnelles chargées dans la mémoire de manière asynchrone et avoir deux liaisons est vraiment agréable d'avoir.
Cela dit, cela signifie-t-il qu'un jour WebApi peut prendre en charge un "contexte de données" sur le client? Je pense que ça pourrait. De plus, avec plus d'outils, un projet Visual Studio peut générer toutes vos méthodes CRUD basées sur un schéma de base de données (ou Entity Framework).
De plus, je sais que je ne parle que de .NET à .NET Frameworks pour travailler avec WCF Data Services ou WebApi, mais je suis conscient du fait que HTML/JS est également un acteur majeur. Je viens de mentionner les avantages que j'ai trouvés en traitant avec une interface utilisateur Silverlight, ou un code côté serveur ASP.NET, etc. Je crois avec l'avènement de "IndexedDB" en HTML5/JavaScript qui ayant un "contexte de données" et un La structure LINQ en JavaScript pourrait également devenir disponible, ce qui simplifierait la possibilité d'interroger des services OData à partir de JavaScript (vous pouvez utiliser DataJS aujourd'hui avec OData). De plus, utiliser KnockoutJS pour prendre en charge MVVM et Binding dans HTML/JS en fera un jeu d'enfant :)
Je recherche actuellement quelle plate-forme utiliser. Je serais heureux d’utiliser l’un ou l’autre, mais j’ai tendance à préférer OData en raison du fait que ma prochaine application concerne principalement Analytics (en lecture seule) et que je souhaite une riche Api RESTful. Je pense que OData + WCF Data Services me le permet car WebApi ne prend en charge que $ take, $ skip, $ filter, $ orderby over Collections. Cela ne prend PAS en charge les projections, les inclusions ($ expand), etc. Je n'ai pas beaucoup de "mises à jour/suppressions/insertions" et nos données sont relativement relationnelles.
J'espère que d'autres participeront à la discussion et donneront leur avis. Je suis toujours en train de décider et j'aimerais entendre d'autres opinions. Je pense vraiment que les deux cadres sont géniaux. Je me demande même si vous devez choisir, pourquoi ne pas utiliser les deux si nécessaire. Du client, il s’agit de toute façon de créer des appels REST. Juste une pensée :).
I hope others will join in the discussion and give their thoughts. I'm still deciding and would love to hear other opinions. I really think both are frameworks are great. I wonder if you have to even choose, why not use both if needed. From the Client it's all about building REST calls anyways. Just a thought :)
Nous croyons que l’API Web fournit la bonne plate-forme pour les services OData et, à ce titre, sera principalement dans cette plate-forme pour les piles de serveurs OData. Nous allons bien sûr continuer à mettre significatif ressources dans les bibliothèques de base et le client OData, mais nous prévoyons d’utiliser réduit l'investissement dans WCF Data Services comme une pile pour créer OData .__ prestations de service.
Alors, semble maintenant que tout est assez clair
L'API Web et WCF Data Services prennent en charge OData prêt à l'emploi. Avec WCF Data Services (WCFDS), c'est automatique. Avec Web API, renvoyez IQueryable à partir de votre contrôleur et marquez la méthode avec [Queryable]. Cela vous donnera la fonctionnalité $filter dont vous parliez. Et si vous vous y prenez de cette façon, les deux peuvent gérer JSON dans la réponse automatiquement en mettant accept=application/json dans l'en-tête de la demande. OData de WCFDS prend en charge un peu plus de mots clés OData que l’API Web (bien que seul le mot clé $expand vienne à l’esprit), mais je suis sûr que le temps y remédiera.
Les clients .NET et les pages HTML peuvent faire facilement appel à ces deux alternatives, mais si vous aimez LINQ et que vous créez des clients .NET, WCFDS peut être ajouté à votre projet en tant que référence de service. Cela vous permet d'ignorer toutes les activités HTTP et d'interroger directement les collections.
En fin de compte, rien ne vous empêche de placer des fichiers .svc dans votre projet ASP.Net MVC. Ce n'est pas un ou l'autre proposition. L'ajout de services de données à votre serveur vous évitera d'écrire de nombreux contrôleurs, mais ne vous empêchera pas d'écrire des contrôleurs supplémentaires si vous le souhaitez.
En d'autres termes :
Si vous souhaitez exposer rapidement un modèle de données (EDM ou autre) et ne pas avoir besoin de beaucoup de code ou de logique métier, WCF Data Services simplifie VRAIMENT et constitue un bon point de départ.
Si vous construisez une API et souhaitez simplement exposer certaines ressources (et leur logique) à l'aide de la syntaxe de requête OData ou de la mise en forme, alors l'API Web ASP.NET est probablement le meilleur endroit pour commencer.
Devaron a donné la critique la plus informative de la WCF vs Web Api que je n'ai pas encore trouvée. Merci. Maintenant, au point que la WCF est trop complexe, je dirai que la complexité n’est pas automatiquement négative. Vous serez reconnaissant de la marge de manœuvre qu'il vous offre à l'avenir. Le défi, comme toujours avec les outils Microsoft, est de ne pas connaître ni contrôler cet avenir. Espérons que Microsoft se retrouvera avec un système plus unifié et qu'il restera en place quelques années.
J'ai aussi un grand système à construire et cela me souligne que le chemin n'est pas plus clair. Je prévois attendre quelques mois de plus pendant que tout se règle. Et personnellement, je suis en train de fouiller pour datajs (consultez également JayData)
En termes simples, résumez-vous du protocole sous-jacent et examinez-le du point de vue du développeur et de l'utilisateur. L'API Web est la première infrastructure reposée par Microsoft basée sur HTTP, et non par WCF. Cela signifie que toutes les caractéristiques et spécifications Restes manquantes seront ajoutées au canal de l'API Web et pas nécessairement à la WCF.
Oui, vous pouvez les implémenter vous-même dans WCF, mais comme le dit la phrase, vous devez les implémenter vous-même.
À titre d'exemple, implémenter aujourd'hui une authentification à 2 facteurs pour une API Web prend moins de 15 minutes avec OWIN, un package de nuget principalement d'authentification/autorisation démarré en tant que projet open source.
Lorsque vous utilisez une pile technologique, utiliser la pile de classes de première classe pour Microsoft est très important. Vous disposeriez même d'innombrables exemples de code et de projets publiés dans MS dans Github, que vous pouvez simplement copier et créer une longueur d'avance dans votre propre projet. Cela fait une différence à tous les niveaux: documentation, exemples de code, ensemble de fonctionnalités, support, applications d'assistance.
Donc, mon conseil simple, si vous voulez créer des applications reposant sur HTTP, utilisez l’API Web (ou ASP.NET Core pour la portabilité) et restez vraiment à l’écart de WCF. Si le protocole n'est pas HTTP et qu'il ne peut vraiment pas être HTTP, utilisez WCF.
C’est la réponse TL; DR à cette question.
WCF est le couteau suisse du tournevis WEB API pour la communication et le transfert de données: WCF peut faire tout ce que Web API peut faire, mais si vous avez besoin de plus (par exemple, en utilisant le protocole TCP), WCF est la voie à suivre.
Voici une excellente comparaison .
API WEB
La première raison d'utiliser l'API WEB est sa légèreté. Cela signifie qu'il est plus simple à mettre en œuvre, plus facile à apprendre, plus facile à gérer, etc. Il est spécialement conçu pour le Web, qui a besoin de services Web RESTful sur HTTP. Il fait ça et ça le fait bien. Si, c'est tout ce dont vous avez besoin, l'API WEB est probablement la solution.
En outre, il est Open Source (si vous vous en souciez)
WCF
WCF fait bien plus que l’API WEB: il prend en charge plusieurs protocoles de transfert, plusieurs modèles d’échange (l’API WEB nécessite l’intégration avec SignalR ou Web Sockets), les services SOAP peuvent être décrits dans WSDL, dispose de fonctionnalités de sécurité supplémentaires, etc. . Choisissez WCF si vous avez besoin de cette fonctionnalité supplémentaire.
OData
OData est tout simplement
Un protocole ouvert permettant la création et la consommation d'API RESTful interrogeables et interopérables de manière simple et standard. source: http://www.odata.org/
En d'autres termes, il s'agit simplement de normaliser une grammaire spécifique pour les requêtes HTTP RESTful. Ce qui fournira les mêmes avantages que n'importe quel protocole. Et à partir d’au moins 2013, les API WCF et WEB permettent l’utilisation d’OData. Donc, cela ne vaut probablement pas la peine de s’inquiéter pour OData.