Quel est le besoin d'Odata lorsque j'ai JSON?
J'essaie de comprendre le point d'Odata et quand cela aurait un sens. En ce moment, comment je travaille, j'utilise ASP.NET et le contrôleur MVC/WebApi pour sérialiser/désérialiser des objets en JSON et faire en sorte que javascript fasse quelque chose avec.
D'après ce que je peux dire, l'avantage d'OData est de pouvoir interroger directement à partir de l'URL ... Mais comme j'écris le code client et serveur, cela n'est pas nécessaire.
Est-ce que quelqu'un analyserait jamais les résultats d'une requête ODaya en javascript ??
Peut-être que OData consiste davantage à fournir un point de terminaison générique à TOUS les clients pour obtenir des informations détaillées à partir d'une requête que JSON ne fournit pas? Donc, si j'étais un fournisseur de données, je suppose que c'est à ça que sert l'odata?
Aidez-moi à comprendre le but et l'utilisation de REST/JSON/ODATA.
JSON est juste un format d'échange de données basé sur JavaScript.
REST est un style d'architecture tandis qu'OData est une implémentation spécifique de REST conçu pour générer et consommer des données, qui prend en charge deux formats, AtomPub et JSON.
Ainsi, la différence entre JSON avec plain REST et OData sont les options dans OData pour la manipulation de données par exemple, si nous interrogeons des données en utilisant le protocole OData, nous pouvons spécifier les options ci-dessous dans l'URI,
- $ orderby
- $ top
- $ sauter
- $ filter
- $ format
- $ sélectionner
Nous pouvons faire de la projection, lier les ressources, etc. et toutes ces options sont disponibles dès la sortie de la boîte. Imaginez maintenant que si nous devions fournir toutes ces fonctionnalités dans notre propre service REST alors nous devions,
- Mettez-les en œuvre tous
- Créez nos propres conventions/mots-clés pour différentes opérations
Cela représente non seulement beaucoup de travail, mais conduit également à des incohérences et crée une courbe d'apprentissage pour nos consommateurs de données.
La notation d'objet JSON ou JavaScript est simplement un format ou un standard pour les données. C'est un format convenu pour transmettre quelque chose comme un nom de connexion OR quelque chose qui doit être consommé par un service REST.
Voir cette partie: http://en.wikipedia.org/wiki/JSON
Bien que dérivé à l'origine du langage de script JavaScript, JSON est un format de données indépendant du langage, et le code pour analyser et générer des données JSON est facilement disponible dans une grande variété de langages de programmation.
Il ne fait partie d'aucun langage de programmation particulier, de sorte que différents systèmes peuvent transmettre des données assez facilement s'ils savent qu'ils utilisent JSON.
Quant à REST c'est simplement un style d'architecture utilisé pour les services web.
Voir cette partie: http://en.wikipedia.org/wiki/Representational_state_transfer
Une façon de penser à cela, c'est si vous vouliez écrire un service Web auquel de nombreux ordinateurs différents peuvent parler .. et échanger des informations. Vous pouvez écrire votre service Web pour accepter les données via l'URL
http://www.myservice.com/specialRESTService?name=punkouter
La réponse pourrait être un objet JSON signalant que vos données ont été reçues.
{
"name": "punkouter",
"status": "service downloaded your data",
}
Je n'avais jamais entendu parler d'OData, alors je l'ai googlé:
OData est construit sur le protocole AtomPub et JSON où la structure Atom est l'enveloppe qui contient les données renvoyées par chaque demande OData. Une demande OData utilise le REST modèle pour toutes les requêtes. Chaque commande REST est une requête http POST, GET, PUT, PATCH ou DELETE (mise en correspondance avec CRUD) où les détails de la commande se trouvent dans l'url.
OBTENIR: obtenir une collection d'entités (en tant que document de flux) ou une seule entité (en tant que document d'entrée).
POST: créer une nouvelle entité à partir d'un document d'entrée.
PUT: mettre à jour une entité existante avec un document d'entrée.
PATCH: mettre à jour une entité existante avec un document d'entrée partiel.
DELETE: supprime une entité.
On dirait que OData est quelque chose d'écrit pour augmenter une architecture de style Vanilla REST .. Mais il semble que cela peut vous donner des choses supplémentaires pour vous aider à démarrer, au lieu d'avoir à écrire des choses à partir de zéro en C # ou quelle que soit la langue que vous utilisez.
Si votre travail vous pousse à utiliser OData, vous utiliserez toujours JSON..mais dans le cadre/standard OData écrit par Microsoft et al.
Est-ce que quelqu'un analyserait jamais les résultats d'une requête OData (sic) en javascript ??
Oui, car (on dirait), il utilise JSON. Il serait parfaitement naturel d'utiliser JS.
Peut-être que OData consiste davantage à fournir un point de terminaison générique à TOUS les clients pour obtenir des informations détaillées à partir d'une requête que JSON ne fournit pas? Donc, si j'étais un fournisseur de données, je suppose que c'est à cela qu'Odata est destiné?
Odata fournirait un service REST .. mais avec certains services standard ajoutés au-dessus d'un simple "générique" REST point de terminaison de service .. les clients ne le font pas faites attention si vous utilisez OData, ou si vous lancez votre propre service C # .. tant que les réponses étaient dans un format convenu (comme JSON). Cependant, pour votre travail, ils veulent peut-être utiliser OData car il fournit beaucoup de " des fonctionnalités prêtes à l'emploi.
OData est une implémentation spécifique du service RESTful avec une norme d'interface. L'avantage est lorsque vous exposez l'API de votre produit et que vous dites qu'il est conforme à la norme OData, car les utilisateurs déjà familiarisés avec OData peuvent l'utiliser facilement sans passer beaucoup de temps à lire la documentation de l'API.
Inconvénient: bien que OData soit excellent pour exposer la base de données sous-jacente, la spécification n'inclut pas la prise en charge des transactions et ne peut pas être utilisée dans les applications où nous pouvons avoir un service RESTful servant à la fois d'interface DB et d'interface de transaction.
Pour la question "pourquoi", il y a une très bonne définition dans le livre API Web RESTful - essentiellement OData implémente un modèle de collection, où une collection est une ressource qui fournit une liste de ressources via des liens.