45 votes

Inconvénients d'OData?

J'étudie actuellement l'utilisation d'OData pour nos services Web Java RESTful. J'ai une longue liste d'avantages à utiliser OData qui constituent un bon argument pour l'utiliser. Cependant, après avoir lu de nombreux articles sur OData, je n'ai pas vu de liste d'inconvénients pour prendre une décision finale.

Est-ce que quelqu'un connaît les inconvénients d'utiliser OData (odata4j dans ce cas)?

Merci

Sarah

17voto

A Aiston Points 477

Certaines requêtes ne peut tout simplement pas être exécutée et que vous finissez par la création de points de vue - par exemple, voir ce post: service WCF opérations pour retourner un objet graphique. C'est parce que vous ne pouvez pas filtrer l'étendue des enregistrements par exemple, dire que vous avez des gens avec des ordres et que vous voulez tous les peuples et de leurs commandes de gâteaux; si vous commencez votre requête OData avec des personnes et d'étendre les commandes que vous pouvez obtenir toutes les personnes qui ont commandé des gâteaux, mais, vous aurez aussi l'ensemble de leurs commandes, et pas seulement ceux pour les gâteaux. La plupart du temps ce n'est pas un problème, puisque vous pouvez activer la requête sur la tête, c'est à dire commencer avec les commandes et d'élargir le peuple. Parfois, cependant, il ne peut pas être fait, et vous avez besoin pour créer une vue.

Pas d'équivalent pour le SQL, vous devez le faire le long chemin avec un tas de rup.

Agrégats, soit vous devez faire un appel supplémentaire à un OData fonctionnement ou de le faire côté client, ce qui n'bon si vous voulez des données de page et d'afficher des agrégats.

Essayez de coller avec JSON, il est trop gonflée avec les données réelles de prendre un petit morceau de la packetsize

En fonction de votre service - obscur et inutile messages d'erreur qui avez-vous ramper à travers OData mise à jour de postes à essayer de savoir exactement ce qui a causé l'erreur.

Si je peux penser de plus, je vais revenir et ajoutez-les.

Il a été un long temps depuis votre post original, peut-être que vous avez découvert quelques autres inconvénients vous-même?

9voto

Boris Nikolaevich Points 920

Un inconvénient est que vous n'écrivez pas votre propre API, propriétaire et encombrante, ni la documentation qui l'accompagne, afin que les consommateurs sachent comment écrire des requêtes concernant votre service.

Non, attendez, ce n'est pas vraiment un désavantage, alors je suppose que je ne peux pas vraiment penser à une solution immédiate. <sourire />

9voto

À mon avis, l'inconvénient avec OData (en face de l'internet public) avec les paramètres de la requête que le client peut ajouter à l'url de filtrer ce que l'alimentation montre. OData permet au client de essentiellement une base de données d'appel/de la logique sur les données de retour d'un flux "sur mesure".

Ce couple le client à l'avance et ils ont besoin de la connaissance préalable de ce qu'ils peuvent utiliser et filtre (qui, je pense, va à l'encontre du RESTE notion de détectabilité). Aussi, cela signifie qu'ils sont à l'utiliser d'une manière que vous ne pouvez pas vraiment voir/contrôle ce qui signifie que leur application client pourrait être très étroitement couplé à votre flux et la base de données d'appel/de la logique qui lui est annexé (il y a beaucoup de méthodes disponibles pour le client d'utiliser l'url).

Dans un environnement contrôlé ou avec seulement quelques les consommateurs, cela peut être un avantage pour Odata comme il est facile et puissant pour l'utilisateur final.

Mais, à mon avis, si elle est exposée au public, ce qui pourrait donner des maux de tête à chaque fois que vous avez besoin de modifier votre alimentation ou de mise à niveau que vous avez pour vous assurer de ne pas tout casser "inconnu" des implémentations. Si les fonctions sont disponibles, les gens vont l'utiliser . . .

Pour le moment, cette fonctionnalité ne peut pas être désactivé, mais est disponible par défaut.

5voto

Peter Aron Zentai Points 3760

En ce qui concerne V2, le seul inconvénient que je constate est l’absence de fonctionnalités de requête pour les relations un-à-plusieurs à des fins multiples. Ainsi, si les auteurs et les articles de votre modèle, vous pouvez interroger des articles avec des attributs d'auteur dans la requête, mais pas l'inverse: vous ne pouvez pas interroger des auteurs avec des articles spécifiques.

À partir de OData V2 Any, tous les opérateurs ne sont pas non plus pris en charge, mais cette question est traitée dans la V3 (sur la base des spécifications préliminaires mais fermées).

2voto

Spécifiquement pour OData et Java4Odata, il y avait quelques problèmes de compatibilité, je crois. Nous exposent OData et ont une autre équipe de le consommer à partir de Java. Ils n'ont pas été entièrement satisfait et n'a apparemment eu beaucoup de discussions sur la liste de diffusion à ce sujet.

En outre, OData ne semble pas obtenir aussi populaire que Microsoft devrait (promis). Ainsi, les avantages qui sont là ne sont vraiment présents si il y a des consommateurs en mesure de faire correspondre les producteurs. Par exemple, OData vous donne de navigation et les données de la requête paradigmes, mais si ils ne sont pas utilisés, ce qui est à gauche?

Et sans réelle les consommateurs et les producteurs dans plusieurs langues, OData est tout aussi bon que n'importe quel autre protocole propriétaire.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X