De hecho, he implementado o estoy usando las 3 opciones publicadas, así que daré mi opinión. Ahora que ha aclarado lo que busca un poco, es más fácil responder.
OData
OData es ideal para aplicaciones internas cuando:
- Usted es el servidor y el cliente.
- Está utilizando Entity Framework.
- No utiliza herencia en sus modelos y no espera consultar subcolecciones.
Odata es increíble porque puede usar IQueryable en el lado del cliente. Esto viene con algunas limitaciones sin embargo. Los dos fuera de mi cabeza incluyen que trabajar con modelos heredados es un poco incómodo y usted can't do nested collections.
También hay un problema con no saber realmente qué es supported LINQ capabilities are.
Recomendaría OData si realmente necesita una capa de servicio y solo espera hacer simples operaciones CRUD con ellos. El principal problema con cada problema OData resulta en una pared dura a la que no se puede mover a veces. El código de consumidor del cliente es realmente la mejor parte y si no está usando C# para consumir, probablemente no valga la pena.
También sin utilizar la compatibilidad de metadatos automáticos de EF, estará escribiendo la misma cantidad de código para ajustarse a un esquema que sus consumidores pueden o no disfrutar escribiendo. Si bien hay un contenedor Rails para OData, todo esto es relativamente nuevo. No veo a OData en la naturaleza, además de socios de MS realmente grandes.
La autenticación y el filtrado OData también son bastante básicos. Escribirá mucho código relacionado con permisos usted mismo si necesita limitar los datos. Si alguna vez desea que SELECT * FROM TABLE esté limitado por permisos, prepárese para escribir un código incómodo.
MVC 2
MVC es bastante bueno para hacer un servicio REST. Tiene soporte verbal y return JSONResult es tan fácil como puede ser. El único inconveniente potencial es que usted codifica una gran parte del manejo del error y todos sus modelos de vista deben heredar de una clase base que muestra códigos de estado y mensajes de error.
También es posible que desee ajustar un poco el motor de visualización dependiendo de qué tan elegante o convención desee que sean las respuestas de sus mensajes. El GRAN beneficio de MVC es muy extensible y puedes hacer casi lo que quieras. Estoy interesado en combinar formularios/llamadas ajax/servicios de descanso en la misma acción de controlador. Implementar una vez, obtener tres sabores de la misma operación. Sería difícil hacer que MVC se quede corto porque puede ser retorcido para hacer casi cualquier cosa que necesite.
Una gran ventaja para un servicio de MVC es que puede introducir una pequeña interfaz de usuario de administrador en una aplicación que se implementa junto con el servicio. Muy útil para no tener dos sitios para implementar.
WCF REST
Así que sólo estoy usando resto WCF en una capacidad muy limitada y parece ... bien ... He utilizado WCF durante 3 años y siempre estoy satisfecho con cuán frustrantemente complejo es extenderlo. Al igual que ODATA, se encontrará con clases selladas y cavernas no extensibles de funcionalidad muy rápido si se sale de los caminos trillados. Esto está en contraste directo con la cantidad de extensibilidad de MVC.
El otro problema es su construcción en la parte superior de WCF y toda la locura que conlleva. Siempre he dicho que se requiere un doctorado para usar WCF de manera efectiva. Rick Strahl tenía un buen artículo sobre el pain points of WCF REST. No estoy seguro de si las cosas han cambiado, pero vale la pena leerlas.
WCF REST se ve realmente prometedor y lo estoy usando en este momento, simplemente no sé lo suficiente como para recomendarlo.
Puntos principales
Si no conoce a sus consumidores entonces yo supongo que no conoce su API. No construyas un servicio hasta que tengas un caso de uso y puedas codificarlo.
MVC es el más extensible y si está familiarizado con la forma en que funcionan las cosas bajo las sábanas, probablemente sea mejor que implementar algo de MS difícil de extender como OData y WCF.
Todos los "grandes" como Facebook, Amazon, PayPal, Ebay tienen API que no se ajustan a ningún patrón o esquema conocido como OData. Su servicio REST es realmente lo que usted hace de él. Esto se relaciona con el # 1. Concéntrese en hacer que sea fácil para un consumidor trabajar primero.
No hay suficiente información para responder la pregunta. Mire las respuestas ya. No tienen sustancia y solo "usan esto porque yo tengo". La única forma de responder estas preguntas es comparando las características con sus requisitos exactos. Debido a que no ha proporcionado nada además de "bajo ancho de banda", que no tiene nada que ver con el marco subyacente y "muchos clientes", que es la definición misma de REST, es casi imposible darle ningún consejo sólido. – jfar
@Alex:/Interpretación impar de la pregunta considerando que está pidiendo "lo mejor" y citando "WCF 4, ASP.NET MVC 2 y WCF REST" – jfar
@Alex gracias. @jfar intenté hacerlo más específico para ti. Solo quiero que alguien me diga si han batallado mucho en cualquiera de las rutas y que ha descubierto que es perfecto o defectuoso – BritishDeveloper