I've actually implemented or am currently using all 3 of the posted options so I'll give my take. Now that you've clarified what your looking for a little its easier to answer.
OData
OData is great for internal applications when:
- You are both the server and the client.
- You are using Entity Framework.
- You do not use inheritance in your models and are not expecting to query sub-collections.
Odata is awesome because you can use IQueryable on the client side. This comes with some limitations though. The two off the top of my head include that you working with inherited models is a little awkward and you can't do nested collections.
There is also an issue with not really knowing what the supported LINQ capabilities are.
I'd recommend OData is you absolutely need a service layer and only expect to do simple CRUD operations with them. The main problem with every OData problem results in a hard wall you just can't get around sometimes. The client consumer code is really the best part and if you aren't using C# to consume its probably not worth it.
Also without using EFs auto metadata support you'll be writing just the same amount of code to conform to a schema your consumers may or may not enjoy writing against. While there is a Rails wrapper for OData all of this is relatively new. I don't see OData in the wild yet besides really big MS partners.
OData authentication and filtering is also pretty bare bones ATM. You'll be writing a lot of permission related code by yourself if you need to limit data. If you ever want SELECT * FROM TABLE to be limited by permissions be prepared to write some awkward code.
MVC 2
MVC is pretty good for making a RESTful service. You have verb support and return JSONResult is as easy at it can be. The only potential downside is your coding a lot of the error handling yourself and all of your view models should inherit from a base class that shows status codes and error messages.
You also may want to tweak the view engine a little depending on how fancy or convention driven you want your message replies to be. The HUGE benefit to MVC is its very extensible and you can do almost whatever you want. I'm big into combining forms/ajax calls/and rest services into the same controller action. Implement once, get three flavors of the same operation. It would be hard to make MVC fall short because it can be twisted to do almost anything you'd need.
A big benefit to an MVC service is you can sneak a little admin UI in a the application that gets deployed along with the service. Very handy to not have two sites to deploy.
WCF REST
So I'm only using WCF rest in a very limited capacity and it seems... ok... I've used WCF for 3 years and I'm always unhappy with how frustratingly complex it is to extend it. Just like ODATA you'll run into sealed classes and unextensible caverns of functionality pretty quick if you go off the beaten path. This is in direct contrast to MVC's amount of extensibility.
The other problem is your building on top of WCF and all the insanity that goes along with it. I've always said it requires a PhD to use WCF effectively. Rick Strahl had a good article about the pain points of WCF REST. Not sure if things have changed but its worth a read.
WCF REST looks really promising and I'm using it right now I just don't know enough about it to recommend.
Main Points
If you don't know your consumers then I'd assume you don't know your API. Don't build a service until you have a use case and and can code against it.
MVC is the most extensible and if you are familiar with how things work under the covers you'll probably be better off than implementing a hard to extend MS thing like OData and WCF.
All of the "big boys" like Facebook, Amazon, PayPal, Ebay have APIs that don't really conform to any known pattern or schema like OData. Your REST service is really what you make of it. This relates to #1. Concentrate on making it easy for a consumer to work with first.
