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».