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 demander à javascript de faire 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çue 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 REST simple 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, 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 OU 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 l'analyse et la génération de 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, donc 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 modèle REST pour toutes les demandes. 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 REST vanille .. 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 dans le langage que vous utilisez.

Si vous travaillez 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 quelques services standard ajoutés en plus d'un point de terminaison de service REST "générique" simple .. les clients ne se soucient pas si vous utilisez OData, ou si vous lancez votre propre service C # .. aussi longtemps car les réponses étaient dans un format convenu (comme JSON). Cependant, pour votre travail, ils souhaitent peut-être utiliser OData car il offre de nombreuses fonctionnalités «prêtes à l'emploi».

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.

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.