I am trying to understand the point of Odata and when it would make sense. Right now how I work is I use ASP.NET and MVC/WebApi controller to serialize/deserialize objects into JSON and have javascript do something with it.

From what I can tell the benefit of OData is being able to query directly from the URL ... But since I am writing the client and server code there is no need for that.

Would anyone ever parse the results of a ODaya query in javascript??

Maybe OData is more about providing a generic endpoint for ALL clients to get detailed information from a query that JSON does not provide ? So if I was a provider of data then I suppose that is what odata is for ?

Help me understand the purpose and use of REST/JSON/ODATA.


4 Answers 4


JSON is just a data-interchange format based on JavaScript.

REST is an architecture style whereas OData is a specific implemenation of REST designed to generate and consume data, which supports two formats, AtomPub and JSON.

So the difference between JSON with plain REST and OData are the options in OData for data manipulation eg, if we query data using OData protocol, we can specify the below options in the URI,

  • $orderby
  • $top
  • $skip
  • $filter
  • $format
  • $select

We can do projection, link the resources, etc. and all these options are available out of the box. Now imagine if we had to provide all these features in our own REST service then we would have to,

  • Implement all of them
  • Create our own convention/keywords for different operations

It is not only lot of work but also leads to inconsistencies and creates a learning curve for our data consumers.


JSON or JavaScript Object Notation is merely a format or standard for data. It's an agreed upon format for transmitting something like a login name OR something that needs to be consumed by a REST Service.

See this part : http://en.wikipedia.org/wiki/JSON

Although originally derived from the JavaScript scripting language, JSON is a language-independent data format, and code for parsing and generating JSON data is readily available in a large variety of programming languages.

It's not a part of any particular programming language, so different systems can pass around data quite easily, if they know they are using JSON.

As for REST it's simply an style of architecture used for web services.

See this part : http://en.wikipedia.org/wiki/Representational_state_transfer

One way to think about this, is if you wanted to write a web service that many different computers can talk to.. and exchange information. You could write your web service to accept data via the URL


The response back could be a JSON object signaling your data was received.

    "name": "punkouter",
    "status": "service downloaded your data",

I had never heard of OData, so I googled it :

OData is built on the AtomPub protocol and JSON where the Atom structure is the envelope that contains the data returned from each OData request. An OData request uses the REST model for all requests. Each REST command is a POST, GET, PUT, PATCH, or DELETE http request (mapping to CRUD) where the specifics of the command are in the url.

GET: Get a collection of entities (as a feed document) or a single entity(as an entry document).

POST: Create a new entity from an entry document.

PUT: Update an existing entity with an entry document.

PATCH: Update an existing entity with a partial entry document.

DELETE: Remove an entity.

Sounds like OData is something written to augment a vanilla REST style architecture.. But it looks like it can give you some added things to get you going, instead of having to write things from scratch in C# or whatever language you're using.

If you work is pushing you into using OData, you'd still be using JSON..but within the OData framework/standard written by Microsoft et al.

Would anyone ever parse the results of a OData (sic) query in javascript??

Yes, since (it sounds like) it's using JSON. It'd be perfectly natural to use JS.

Maybe OData is more about providing a generic endpoint for ALL clients to get detailed information from a query that JSON does not provide ? So if I was a provider of data then I suppose that is what Odata is for ?

Odata would be providing a REST service.. but with some added standard services on top of a plain "generic" REST service endpoint.. clients don't care if you're using OData, or rolling your own C# service.. as long as the responses were in an agreed upon format (like JSON). However, for your work maybe they want to use OData because it provides a lot of 'out of the box' features..

  • Work does not care.. I just wanted to know what th epurpose of Odata is for..JSON is just a way to represent data .. and so is ODATA.. but.. I guess the question I have is what is a scenario where using REST and returning JSON is not enough.. and using ODATA would be an advantage ?
    – punkouter
    Nov 7, 2013 at 17:48
  • no no, OData is a RESTful service architecture... that uses JSON to represent data. You'd gain nothing by using OData libraries/standards .. nothing that couldn't technically be written by yourself.. but using OData might save you time if you're building things with it.. as opposed to writing things yourself
    – Erik
    Nov 7, 2013 at 21:52
  • json ? But it looks to me the OData returns XML?? Or is it both? im confused.
    – punkouter
    Nov 8, 2013 at 16:42
  • 2
  • From your link "OData supports two formats for representing the resources (Collections, Entries, Links, etc) it exposes: the XML-based Atom format and the JSON format. "
    – Erik
    Nov 8, 2013 at 19:50

For the "why" question, there is a really good definition in the book RESTful Web APIs - essentially OData implements a collection pattern, where a collection is a resource that provides a list of resources through links.


OData is specific implementation of RESTful service with a standard for interface. The advantage being when you are exposing your product's API and say it is compliant with OData standard, for users already familiar with OData can use it readily without spending much time on reading the API documentation.

Disadvantage: While OData is great in exposing underlying database, the specification does not include support for transactions and cannot be used in applications where we can have a RESTful service serving as both DB interface as well as a transaction interface.

Not the answer you're looking for? Browse other questions tagged or ask your own question.