J’étudie l’utilisation d’OData pour nos services Web Java RESTful. J’ai une longue liste d’avantages pour utiliser OData qui constituent un bon argument pour l’utiliser. Cependant, après avoir lu beaucoup d’articles sur OData, je n’ai pas vu de liste des 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
Certaines requêtes ne peuvent simplement pas être exécutées et vous finissez par créer des vues – par exemple, consultez cet article: Opérations du service WCF pour renvoyer un graphique d’object . C’est parce que vous ne pouvez pas filtrer les enregistrements étendus, par exemple, vous avez des gens avec des commandes et vous voulez toutes les personnes et leurs commandes de gâteaux; Si vous lancez votre requête OData avec des personnes et développez les commandes, vous pouvez obtenir toutes les personnes ayant commandé des gâteaux, mais vous obtiendrez également toutes leurs commandes, pas seulement celles pour les gâteaux. La plupart du temps, ce n’est pas un problème, car vous pouvez inverser la requête, c’est-à-dire commencer par les commandes et élargir le nombre de personnes. Parfois, cela ne peut pas être fait et vous devez créer une vue.
Aucun équivalent à SQL In, vous devez le faire dans le long terme avec un tas de ors.
Agrégats, vous devez soit effectuer un appel supplémentaire à une opération OData, soit les utiliser côté client, ce qui n’est pas une bonne chose si vous souhaitez publier des données et afficher des agrégats.
Essayer de restr avec JSON, ATOM est trop gonflé avec les données réelles prenant une petite partie du paquet
En fonction de votre service – des messages d’erreur obscurs et inutiles vous permettant d’parsingr les messages de mise à jour OData en essayant de déterminer exactement la cause de l’erreur.
Si je pouvais en penser plus, je reviendrais les append.
Il y a longtemps que votre post original, peut-être vous avez découvert d’autres inconvénients vous-même?
À mon avis, l’inconvénient d’OData (face à l’Internet public) réside dans les parameters de requête que le client peut append à l’URL pour filtrer ce que montre le stream. OData permet au client d’effectuer essentiellement un appel / une logique de firebase database sur les données pour leur retourner un stream “personnalisé”.
Cela associe le client au stream et nécessite une connaissance préalable de ce qu’il peut utiliser et filtrer (ce qui, à mon avis, va à l’encontre du concept de découverte de REST). En outre, cela signifie qu’ils l’utilisent d’une manière que vous ne pouvez pas vraiment voir / contrôler, ce qui signifie que leur application client pourrait être très étroitement associée à votre stream et à l’appel / la logique de la firebase database. pour le client à utiliser avec l’URL).
Dans un environnement contrôlé ou peu consommateur, cela peut être avantageux pour Odata, car il est facile et puissant pour l’utilisateur final.
Mais, à mon avis, si elle est exposée publiquement, cela peut vous causer des maux de tête chaque fois que vous avez besoin de modifier votre stream ou votre mise à niveau, car vous devez vous assurer de ne briser aucune implémentation “inconnue”. Si les fonctions sont disponibles, les gens l’utiliseront. . .
Pour le moment, cette fonctionnalité ne peut pas être désactivée mais est disponible par défaut.
Un inconvénient est que vous ne pouvez pas écrire votre propre API encombrante et propriétaire et la documentation qui l’accompagne pour que les consommateurs sachent comment écrire des requêtes sur votre service.
Non, attendez – ce n’est pas vraiment un inconvénient, alors je suppose que je ne peux pas vraiment penser à ça.
Pour développer cette réponse et la comparer à SOAP:
SOAP est également une méthodologie totalement acceptable et une norme publiée. Cependant, puisque REST fournit un access sans état léger à l’aide de verbes HTTP, et OData est simplement un ensemble de conventions URI permettant d’accéder à des services REST disparates via une méthodologie commune, l’affiche originale décrivant les services Web Java RESTful réponse de joue ci-dessus dans le contexte de REST et OData. En outre: aucun WSDL n’est requirejs pour OData, car la spécification est commune à tous les services OData, et le service lui-même (lorsqu’il respecte les spécifications) décrit les offres de données.
[Extrait de mon commentaire sur cette réponse.]
En ce qui concerne V2, le seul inconvénient que je vois est le manque de capacités d’interrogation sur les relations un-à-plusieurs vers les multiples. Donc, si les auteurs et les articles de votre modèle, vous pouvez interroger des articles avec des atsortingbuts d’auteur dans la requête, mais pas l’inverse: vous ne pouvez pas interroger des auteurs avec des articles spécifiques.
À partir d’OData V2 Any, tous les opérateurs ne sont pas pris en charge, mais cela est traité dans V3 (basé sur des spécifications préliminaires mais fermées).
En ce qui concerne spécifiquement OData et Java4Odata, certains problèmes de compatibilité sont apparus. Nous exposons OData et une autre équipe la consum depuis Java. Ils n’étaient pas entièrement heureux et avaient apparemment beaucoup de discussions sur la liste de diffusion à ce sujet.
De plus, OData ne semblait pas être aussi populaire que prévu (promis). Ainsi, les avantages qui en découlent ne sont réellement présents que s’il existe des consommateurs capables de rivaliser avec les producteurs. Par exemple, OData vous donne des paradigmes de données de navigation et de requête, mais s’ils ne sont pas utilisés, que rest-t-il?
Et sans de véritables consommateurs et producteurs en plusieurs langues, OData est aussi efficace que tout autre protocole propriétaire.
En examinant les avantages et les inconvénients, on peut considérer les choses de manière abstraite ou par référence à un projet ou à un scénario particulier.
Parlant de manière abstraite pendant un moment, il faut réfléchir à la valeur des «normes». Les normes sont comme les dollars, les gouvernements et les frontières … elles n’existent qu’au point où les gens croient qu’ils existent. Sinon, l’argent n’est que du papier (ou à l’ère du numérique, des chiffres). Donc, la question devient, à quel point cela sera-t-il adopté? C’est quelque chose que je suis venu ici pour découvrir, bien que mon enquête préliminaire suggère qu’il n’y aura pas de technologie omniprésente. Les gens adoptent toutes sortes de nouvelles technologies en grand nombre.
Ensuite, dans les détails, vous pourriez vous retrouver face à des alternatives telles que MongoDB (qui est, je crois, très similaire), en particulier en ce qui concerne les besoins ressentis par votre organisation. Encore une fois, c’est quelque chose que je suis venu découvrir ici.
Ma pensée est que la tendance importante est de ne pas envoyer quelque chose sur le fil qui a déjà été rendu en HTML, mais d’envoyer des données en tant que variantes du JSON et de fournir le Javascript qui sera utilisé par le navigateur pour le rendre. Comme les pilotes pour les différentes variantes JSON apparaissent, il sera sortingvial de changer l’un ou l’autre. En voici un qui sort pour oData:
http://www.rssbus.com/ado/odata/
Je crois que cela vous permettra de prétendre que vous traitez avec Sql Server. Je pense que nous verrons plus de cette abstraction de la couche de type JSON permettant une plus grande liberté vis-à-vis des “standards”. Mais encore une fois, c’est ce que je suis ici pour découvrir.
Je ne connais pas spécifiquement ODataJ4. Je sais qu’il existe un certain nombre de ressources sur http://www.odata.org/, y compris une liste de producteurs et de consommateurs d’odata, ainsi qu’une liste de langues connues pour le soutenir. OData a ses limites dans des domaines et dépend de la version du protocole que vous utilisez. OData est encore en développement à partir de nombreuses implémentations pour prendre en charge intégralement les versions. Donc, si vous êtes après les trucs supplémentaires que vous obtenez dans la v3 du protocole, je pense que vous constaterez qu’un certain nombre d’implémentations ne sont pas encore complètement là.
Au-delà du manque de fonctionnalité des fournisseurs, la seule chose à laquelle je puisse penser, c’est le manque de flexibilité (si c’est un inconvénient). Généralement, dans OData, il y a une façon de faire quelque chose.
Je voudrais juste souligner que odata est publié sous la promesse de spécification ouverte de Microsoft et qu’il n’y a aucune intention de facturer l’utilisation du protocole.
J’espère que ça aide