WCF Data Services (OData) par rapport à l'API Web ASP.NET? Hypermédia?

Je conçois une application distribuée qui comprendra des services REST et une variété de clients (Silverlight, iOS, Windows Phone 7, etc.). J'étais prêt à décider que j'implémenterais mes services REST à l'aide de WCF Data Services (OData) mais maintenant l'API Web MVC 4 m'a fait remettre en question cette décision.

Ce que j'ai aimé à propos d'OData, c'est les capacités d'interrogation d'URI et d'hypermédia que vous obtenez gratuitement. Ce que je n'ai pas aimé, c'est la verbosité de la charge utile OData; beaucoup de caractères inutiles venant sur le fil.

Ce que j'aime dans l'API Web, c'est que les charges utiles sont beaucoup plus concises et qu'elles ont la capacité d'interrogation d'URI d'OData, mais il semble manquer d'hypermédia (prêt à l'emploi, au moins). Mon patron fait également pression pour l'API Web parce que «les pouvoirs de Microsoft la soutiennent et OData n'a pas obtenu de traction».

J'ai donc deux questions:

1) Quelqu'un peut-il commenter le soutien / la traction de l'API Web et d'OData?

2) L'API Web est-elle censée prendre en charge nativement l'hypermédia au moment de la sortie ou y a-t-il des implémentations ou des exemples standard que je devrais examiner?

Merci!

L'API Web fait des données. Voir le blog de Scott Guthrie . Plus précisément:

Composition des requêtes: l'API Web vous permet de prendre en charge facilement les requêtes via les conventions URL OData. Lorsque vous renvoyez un type d'IQueryable à partir de votre API Web, le framework fournit automatiquement une prise en charge des requêtes OData dessus, ce qui facilite l'implémentation de la pagination et du tri.

Je pense également que dans de nombreux cas, la même classe pourrait être la classe WCF traditionnelle et la classe API Web, elles ne sont certainement pas mutuellement exclusives.

L'API Web profite plus nativement du protocole http. Odata est un standard ouvert adopté par de nombreux grands joueurs. Je ne peux parler que de mon expérience en jouant avec Odata et en découvrant récemment l'API Web et en faisant des recherches.

OData est cool parce que c'est une norme réelle. Vous pouvez facilement créer une base de données et l'exposer via HTTP. Cela signifie que vous pouvez parcourir la structure de votre table sans aucune configuration (je le dis de manière lâche). Vous pouvez également exécuter des requêtes via l'URL, qui peut inclure un léger LINQ:

/products/orders/[put some linq-ish query here]

C'est sans doute bon ou mauvais. L'authentification est standard et l'a construite.

L'API Web, est plus intéressante de mon point de vue. Il a utilisé la fonctionnalité HTTP (messages d'erreur, et al.) Et est un peu plus "natif" pour les vraies requêtes RESTful. Je n'y ai vraiment pas trop joué. Mais j'ai lu et j'ai en quelque sorte "entendu" que MVC et l'API Web pourraient se "marier" un jour, encore une fois, peut-être bien, peut-être mal ...

Lorsque je jouais avec OData, j'ai créé un processus stocké, mappé à la surface de l'entité, configuré un type de retour fort, puis connecté à une demande d'URL et à BANG, il y a ma demande RESTful mappée à mon proc stocké de résultat tapé. C'était assez simple et j'ai pu obtenir exactement ce dont j'avais besoin.

En conclusion, je n'ai pas eu la chance de jouer avec WCF API avec trop de détails, mais je dirais que c'est la voie à suivre pour le développement client car il s'agit plutôt d'une approche puriste de REST. Si vous allez faire des appels de va-et-vient plus ou moins «droits» et récupérer des «Afficher les modèles», cela fournira une interaction plus native.

D'autre part. Si vous effectuez des requêtes complexes (ish) sur les données en fonction de l'interaction avec le client et que vous souhaitez "créer" la logique de requête et la transmettre en tant que paramètre, alors Odata pourrait fonctionner.

La façon dont je les regarde est si j'ai besoin d'exposer mes données dans un format structurel (c'est-à-dire une structure de table / relation) et de les interroger directement depuis un client, alors Odata fonctionnera mieux. C'est aussi bon pour permettre à "Autres" d'accéder aux données (avec une authentification appropriée, etc.), c'est pourquoi il adhère au protocole OData

Si vous voulez des requêtes RESTful où vous dictez l'URL (/ products / Orders / 22, et créez des "jeux de résultats" complexes à partir de votre code managé et de votre structure de données "cachés" ET vous pourriez également bénéficier des messages de réponse HTTP, L'API Web serait probablement la meilleure solution.

encore une fois, tout cela provient de la recherche et du jeu. Je n'ai pas implémenté non plus dans un scénario d'application de production / complet. Je pense qu'ils auront tous les deux leurs forces et leurs faiblesses, et il y a certainement un certain chevauchement

Du point de vue hypermédia, définitivement API Web. OData, qui est basé sur AtomPub, n'est qu'un moyen d'exposer une base de données en utilisant HTTP, vous n'obtenez qu'un ensemble limité de transferts d'état prédéfinis (CRUD). En revanche, un service hypermédia est comme une application, adaptée au client. Avec l'API Web, vous pouvez incorporer tous les liens que vous souhaitez, et vous pouvez également utiliser la syntaxe de requête OData. En fait, la meilleure solution hypermédia dans la pile Microsoft est ASP.NET MVC, si vous êtes prêt à utiliser HTML comme format de base.