This seems like overkill really. Rest is just fine. If i have to look for 10 minutes to figure out how to share my data with oData, why bother? It's available with REST already.
oData is REST. It is a specific protocol for creating REST-based queries. I think what you see as overkill is really the ability to handle diverse scenarios.
I agree, I think it is adding a layer that might be another layer that needs tools to even use. REST is the way now. They are just trying to describe the content in the REST transport. But I think we have that already with JSON, JSONSchema, ATOM and others. Trying to write wrappers and descriptions too specific or globally acceptable is what got us in trouble with Web Services built on SOAP and bloated XML. This looks like it is more ontology focused (OWL) but probably overkill.
The SOAP tragedy was my first thought. In 2000, SOAP was just coming out and I had written an XML to Javabean mapper based on reflection that was much more lean and with much higher throughput than SOAP. At that time, Microsoft was the biggest SOAP proponent and was pushing it very hard.
I thought it was bloated and unnecessarily complicated to integrate and conform to, so we skipped on it. I suspect most will skip on oData too unless it is simplified. It's an architect's abstract dream and I think some people need to wake up.
I suspect the only people who will choose oData are the business managers running budget legitimizing projects.
http://live.visitmix.com/MIX10/Sessions/KEY02