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.
Je suis OData depuis un moment et aussi 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", car cela signifie qu'ils ne soutiennent pas OData ?? OMI, ils soutiennent les deux et actuellement il y a un chevauchement minimal. Windows Azure Data Market expose ses 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 de MS le prennent également en charge, tels qu'Excel PowerPivot. C'est un cadre de requête très puissant en matière de données relationnelles. Et comme il est RESTful, n'importe quel langage, framework, appareil, etc. peut s'y intégrer.
Voici ce que j'aime à propos des services de données OData + WCF:
OData + WCF Data Services a finalement permis aux applications client 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 sont peu maniables et nécessitent des changements constants chaque fois qu'une interface utilisateur veut quelque chose de légèrement différent. L'application cliente pouvait uniquement spécifier des paramètres pour dicter les critères à renvoyer. Ou faites comme je l'ai fait et «Sérialisez» les expressions LINQ et passez-les en tant que paramètres et réhydratez-vous dansExpressions<Func<T,bool>> sur le serveur. C'est décent. J'ai fait le travail, mais je veux utiliser LINQ sur le client et le faire traduire sur le Web en utilisant REST, ce qui est exactement ce que permet OData et je ne veux pas utiliser mon propre "hack" d'une solution.
C'est comme exposer "TRANSACT SQL" sans avoir besoin d'une chaîne de connexion DB. Fournissez simplement une URL et 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 basées sur les rôles ou toute autre configuration de données. Je préfère le faire dans ma couche API Web que dans SQL (comme la construction de vues ou de processus stockés). Et maintenant que les applications peuvent créer elles-mêmes des requêtes, vous verrez des outils de création de rapports ad hoc et BI commencer à exploiter OData et permettre aux utilisateurs de définir leurs propres résultats. Ne pas se fier aux 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 des données ET vous obtenez un «Contexte de 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é les services de données WCF au lieu des services RIA, mais à l'époque, ils ne prenaient pas en charge les annotations de données ou les actions, mais maintenant c'est le cas :) Les services de données WCF ont un autre avantage par rapport aux services RIA, qui est la possibilité d'effectuer des «projections» du client. Cela peut améliorer les performances, au cas où je ne souhaite pas renvoyer toutes les propriétés d'une entité. Avoir un "contexte de données"
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 interrogeables + actions (appels pour appeler des opérations, c'est-à-dire des flux de travail, des processus d'arrière-plan) sur 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 des services de données WCF est le «contrôle» que vous perdez sur la pile HTTP. J'ai trouvé que le plus gros défaut était dans les IQueryable<T>méthodes qui retournent les collections. Contrairement aux services RIA ET WebApi, vous N'AVEZ PAS un accès complet pour développer la logique de la méthode IQueryable. Dans les services RIA et WebApi, vous pouvez écrire le code de votre choix tant que vous revenez IQueryable<T>. Dans WCF Data Services, vous avez UNIQUEMENT accès pour ajouter une instruction «Where» à l'aide deExpression<Func<T,bool>> méthodes d'intercepteur. J'ai trouvé cela décevant. Notre application actuelle utilise les services RIA et je trouve 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 juste quelque chose
En outre, WCF Data Services ne prend pas encore totalement en charge tous les opérateurs LINQ. Cependant, il prend toujours en charge plus que WebApi.
Et WebApi ???
- J'aime le contrôle sur Http Request / Response
- C'est facile à suivre (en tirant parti des modèles MVC). Je suis sûr que d'autres outils viendront.
À partir de maintenant (à ma connaissance), il n'y a pas de prise en charge du «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 d'entité comme les services de données WCF / OData est. Il peut exposer des collections d'objets de modèle à l'aide de IQueryable / IEnumerable, mais il n'y a pas de «propriétés de navigation» de clé primaire / clé étrangère (c'est-à-dire customer.Invoices) à utiliser une fois que les entités sont chargées sur le client, car il n'y a pas de «contexte de données» qui les charge de manière asynchrone (ou en un seul appel en utilisant $ expand), et gère les changements. Vous n'avez aucune "représentation" générée par code de votre modèle de données d'entité sur le client, comme vous le faites 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 devez remplir manuellement les données et gérer les «factures» à définir avec chaque «client» une fois qu'elles sont récupérées sur le Web. Cela peut devenir délicat, surtout avec toutes les choses Async. Vous ne savez pas quels appels reviendront en premier. Cela peut être difficile à expliquer ici, mais lisez simplement les informations sur le "Contexte des données" dans les services RIA ouServices de données WCF . Donc, lorsque vous traitez avec les 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, en particulier dans Silverlight, WPF et maintenant Windows 8 Metro. Avoir des entités relationnelles chargées en mémoire de façon asynchrone et avoir deux liaisons est vraiment agréable à 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 c'est possible. De plus, avec plus d'outils, un projet Visual Studio pourrait 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 mentionne .NET à .NET Frameworks que lorsqu'il s'agit de travailler avec WCF Data Services ou WebApi, mais je suis très conscient 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 qu'avec l'avènement de «IndexedDB» en HTML5 / JavaScript, avoir un Le framework LINQ en JavaScript pourrait également devenir disponible, rendant la possibilité d'interroger les services OData encore plus facilement à partir de JavaScript (vous pouvez utiliser DataJS aujourd'hui avec OData). De plus, l'utilisation de KnockoutJS pour prendre en charge MVVM et la liaison en HTML / JS en fera un jeu d'enfant :)
Je recherche actuellement la plateforme à utiliser. Je serais heureux d'utiliser l'un ou l'autre, mais j'ai tendance à me pencher vers OData sur la base du fait que ma prochaine application concerne principalement Analytics (lecture seule) et que je veux une API RESTful expressive riche. Je crois que les services de données OData + WCF me le donnent parce que WebApi ne prend en charge que $ take, $ skip, $ filter, $ orderby sur les collections. Il ne prend PAS en charge les projections, comprend ($ expand), etc. Je n'ai pas beaucoup de "mises à jour / suppressions / insertions" et nos données sont assez relationnelles.
J'espère que d'autres se joindront à 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 excellents. Je me demande si vous devez même choisir, pourquoi ne pas utiliser les deux si nécessaire. À partir du client, tout est question de créer des appels REST de toute façon. Juste une pensée :)