OData is the Open Data Protocol. It is an open web protocol started by Microsoft to expose data using existing web technologies. This is based on Representational State Transfer (REST) full architecture. HTTP, AtomPub (similar to RSS, but specifically introduced special XML format for OData), JSON are all supported.
Here, the URL is the primary operator on the data query.

WCF OData Service

In Visual Studio 2013, there is a template to create a WCF OData service. So, we can easily create an OData Service using Visual Studio 2010.

Example of OData Service has been used

1. Last (2010) football world cup (S.A), the scoring website was done using an OData Service.

Why should we use an OData Service? 

1. OData is based on the REST architecture, so we can retrieve data based on an URL.
2. It also supports HTTP, Atom Pub as well as JSON format.
3. It has support for any type of data source. Even you can use a custom class as a data source.
4. No need to create a proxy service object. So, it is lightweight to use.
5. You can create your own custom methods and expose it.
6. Since it is lightweight, the interaction between server and client is fast. Thus, performance is good.
7. It offers full CRUD support by using the different HTTP methods:
   • GET: Gets one or many entries.
   • POST: Create a new entry.
   • PUT: Update an existing entry.
   • DELETE: Remove an entry.

8. A WCF Data service can expose an entity model via an URI.
9. A WCF Data service could be consumed by any type of client like Windows, SilverLight, Web, AJAX and console.

Limitations

1. Since it is purely URL based, it is less secure.
2. Not every query operator in LINQ is available in OData like Filter, Skip, Take etc.

Working of a WCF Data Service

There are five components.

1. DataBase.
2. Data Access layer using ADO.Net Entity model or LINQ.
3. Entity Model Implementing Iqueryable and Iupdatable Interface.
4. WCF Data Service exposing CRUD Operations on entity model as REST Service.
5. Consuming it on various types of clients.

Supported Message Format

1. JSON
2. XML (ATOM)

Microsoft has made it obvious that they are taking OData protocol very seriously by integrating it into SharePoint, 

Generally speaking, OData extends AtomPub. AtomPub, as specified in [RFC5023] is appropriate for use in Web services which need a uniform, flexible, general purpose interface for exposing create retrieve update delete (CRUD) operations on a data model to clients. It is less suited to Web services that are primarily method-oriented or in which data operations are constrained to certain prescribed patterns.

Let me paraphrase that.  If all your service is going to do for your client is “CRUD” on generic data then OData is appropriate.  As long as everyone keeps this in mind going forward we should not run into too much trouble.  However, there is a problem with this statement.  REST is not really appropriate for doing CRUD.  

ODBC allows clients to initiate transactions across multiple requests. REST does not allow this as it would violate the stateless constraint.  REST does not need this because it is intended to address a completely different layer of the application architecture than ODBC.  REST provides a way to deliver Domain services.  I.e.  If you maintain weather data, REST provides you a easy way to expose “Today’s Weather”, “Last Week’s weather for Detroit”, “Average Rainfall in Orlando for the month of June”.  ODBC is aimed at the layer that exposes the data points for a specific place at a specific date and time. 

ODBC exposes dumb data, REST exposes intelligently presented information.

In an ODBC application it is the client that does something intelligent with the data before presenting it to the user.  In a REST application, usually the client simply makes the “intelligent information” pretty.  REST and ODBC are not comparable.

So is OData useful?  Absolutely it is useful to people who want to manipulate generic information, like for example SharePoint lists, or data to feed into PowerPivot or Excel.  If you have a need to expose a generic data store to a client that will do graphing, statistical analysis, or some kind of visualization like rendering Mars Rover data then it could be very useful. 

However, if you want to provide a service that delivers intelligent information that is specific to a particular domain then OData is not appropriate.

Beyond my fear of developers attempting to use OData for unintended purposes there are few other things that I think should be fixed in the OData spec. 

The Atom Entry content element should not use application/xml as the media type.  The content contains XML that is specifically related to the Entity Data Model and should be identified as such.  A media type such as application/EDM-Instance+xml may be sufficient.  What would be even better is if that content element contained a link to the CSDL file that defines the EntityType and that is currently accessed by constructing an URI with [Service]/$metadata.  

Client side URI construction is really nasty habit to get into.  I think for the most part, MS can get away with the construction of query parameters like $skip, $top, and $orderby, but to actually construct the path segments of a URI is just going lead to client-server coupling that will hurt in the future.