ODATA is a open standard protocol initiated and led by Microsoft but it is supported by different platforms vendors. You can find more about this protocol from http://www.odata.org/.General idea of ODATA is expose data over HTTP services for query or update.ODATA embraces REST architectural style.One thing we give up with REST in general is that if you have ever been expose to WCF, WCF includes metadata with the services and that means you could generate client proxies to call those services very easily.When you go to REST based services you could lose that.REST in general has no protocol for metadata but the ODATA includes metadata specification for services, that means for ODATA endpoint you can expose that metadata and has some client side code generation for consuming the endpoint.ODATA is broken down in to two parts
1.ODATA Query Syntax : URL syntax for expressing queries

• Data Service URI
• Entity set name
• Navigation Property
• Operators and functions

2.ODATA Formatting: ATOM publising Protocol or JSON formatting

• application/atom+xml or application/json
• JSON Verbose vs JSON Light

     ODATA also leverages HTTP verbs such as GET,POST,PUT,DELETE,PATCH,MERGE

ODATA Supported Platforms

• WCF Data Services(Initial OData Microsoft platform)
• Node.js,PHP,Java
• SSRS(SQL Server Reporting Services)
• Sharepoint
• Windows Azure Table Storage
• Windows Azure Data Marketplace
• IBM WebSphere/DB2/Informix
• ASP.NET WebApi

Enjoy..Reading

Introduction

REST stands for Representational State Transfer It is truly a different way of thinking about service design than traditional service oriented approaches.Instead of focusing on exposing operation or method for remote invocation you focus on exposing resources.Resources are something like a data collection.it is the easiest way  for think about it.You can certainly use rest services for command and control type scenarios.for example you might have  some remote piece of equipment you trying to control , it could be a scientific device you trying to come across with or any number of scenarios like that. You need to send a service call for make it happen. If you can think as a resource you are manipulating it comes in the REST architecture style.So that the resources are things you need to communicate with and way you communicate with representations of those resources that’s why the representation parts of the names come in.
Comparing REST and SOAP
REST is a architectural style and SOAP is nothing more than a message format and is protocol for how you structure a message doesn’t say anything about how you get the message from POINT A to POINT B.REST is fully embraces on HTTP protocol which is capable of expressing more than just how to structure a message.It also has headers,status code,verbs and other  things that allow you to express semantics about the communication itself.Now basically you can write number of elements to do with HTTP protocol that we can leverage fully embrace rest.

URI
In service oriented systems the URI only used to represents the service address,how you get the service location.and the soap message takes over from there to express all other aspects, what is that message represents,what action should be invoked and so on.In REST based system URI also express what resource you are trying to manipulate or communicate with.Additionally you can add parameters in to the URI you seen either URI parameters or querystring parameters and those can be passed in to the target service method that you are invoke on
the service itself.
HTTP verb
HTTP also has verbs associated with it. Doing soap based services only verb used is POST verb.In Rest you can leverage the full range of verbs such as GET,POST,PUT,DELETE.
HTTP Headers
HTTP also has headers associated with it . We can also include content negotiation saying that what the media types that client request and what the content type is. Additionally you can leverage HTTP messages have status code , the status code indicate the service status whether the call is success or not and also there are some other things can express in the headers such as security,ETags allow you to do caching in the client and also you can put custom headers in the HTTP messages also.
HTTP Body
Anything you want to serialize in the body there is a parameters in to the method or response or return type from that method but you can also encode in a particular way by using media types. Media types could be standardize once like application/json or application/xml and you can  put custom media types also.And there is Hyper media for example a customer has a collection of orders instead of embedding the order objects in the response you can embed links to related order objects you can also further actions you can take against that service such as URL to update that object or do you have read only access then you wouldn’t have to update link in the representations.So all of  these things comes together to form whole REST about.