See this part : http://en.wikipedia.org/wiki/JSON
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.
"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.
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..