Actualmente, existen otras diferencias importantes entre WebApi y WCF Data Services, que nadie parece mencionar. Me gustaría que MS publicara un buen artículo comparando los dos.
He estado siguiendo OData por un tiempo y también WebApi. Siempre he encontrado algunas distinciones importantes.
En primer lugar, no estoy seguro de lo que quiere decir su jefe con "MS está respaldando WebApi", como si significa que no respaldan OData. En mi opinión, están respaldando a ambos y actualmente hay una superposición mínima. Windows Azure Data Market expone sus datos usando OData, Azure Table Storage usa OData, SharePoint 2010 permite consultas OData sobre sus datos, y otros productos de MS también lo admiten, como Excel PowerPivot. Es un marco de consulta muy poderoso cuando se trata de datos relacionales. Y debido a que es RESTful, cualquier lenguaje, marco, dispositivo, etc. puede integrarse con él.
Esto es lo que me gusta de OData + WCF Data Services:
OData + WCF Data Services finalmente ha permitido que las aplicaciones cliente sean más "expresivas" al consultar datos a través de la Web. Antes, siempre teníamos que usar ASMX o WCF para construir API web rígidas que se vuelven difíciles de manejar y requieren cambios constantes cada vez que una interfaz de usuario quiere algo ligeramente diferente. La aplicación cliente solo podía especificar parámetros para dictar qué criterios devolver. O haga lo que hice y "serialice" las expresiones LINQ y páselos como parámetros y rehidrate Expressions<Func<T,bool>>en el servidor. Es decente. Hice el trabajo, pero quiero usar LINQ en el Cliente y traducirlo a través de la Web usando REST, que es exactamente lo que permite OData y no quiero usar mi propio "truco" de solución.
Es como exponer "TRANSACT SQL" sin la necesidad de una cadena de conexión DB. Simplemente proporcione una URL y ¡vaya! Empiece a consultar. Por supuesto, tanto WebApi como WCF Data Services son compatibles con la autenticación / autorización, por lo que puede controlar el acceso y agregar declaraciones "Where" adicionales basadas en roles u otra configuración de datos. Prefiero hacer esto en mi capa Web Api que en SQL (como crear vistas o procesos almacenados). Y ahora que las aplicaciones pueden crear consultas por sí mismas, verá que las herramientas de informes de BI y Ad-Hoc comienzan a aprovechar OData y permiten a los usuarios definir sus propios resultados. No depender de los informes estáticos donde tienen un control mínimo.
Al desarrollar en Silverlight, Windows 8 Metro o ASP.NET (MVC, WebForms, etc.), simplemente puede agregar una "Referencia de servicio" en Visual Studio al Servicio de datos WCF y comenzar rápidamente a usar LINQ para consultar datos Y obtendrá un "Contexto de datos" en el Cliente, lo que significa que rastrea los cambios y le permite "Enviar" sus cambios de forma atómica al Servidor. Esto es muy similar a los servicios RIA para Silverlight. Habría usado WCF Data Services en lugar de RIA Services, pero en ese momento, no admitía DataAnnotations o Actions, pero ahora lo hace :) WCF Data Services tiene otra ventaja sobre RIA Services, que es la capacidad de realizar "Proyecciones" del Cliente. Esto puede ayudar con el rendimiento, en caso de que no quiera devolver todas las propiedades de una entidad. Tener un "contexto de datos"
Por lo tanto, WCF Data Services es excelente si tiene datos con relaciones, especialmente si está utilizando SQL Server y Entity Framework. Podrá exponer rápidamente datos y acciones que se pueden consultar (llamadas para invocar operaciones, es decir, flujos de trabajo, procesos en segundo plano) sobre REST con muy poco código. WCF Data Services se acaba de actualizar. Lanzamiento de una nueva versión. Vea todas las nuevas funciones.
La desventaja de WCF Data Services es el "control" que pierde sobre la pila HTTP. Encontré que el mayor defecto estaba en los IQueryable<T>métodos que devuelven colecciones. A diferencia de los Servicios RIA Y WebApi, NO tiene acceso completo para desarrollar la lógica en el Método IQueryable. En RIA Services y WebApi, puede escribir el código que desee siempre que regrese IQueryable<T>. En WCF Data Services, SOLO tiene acceso para agregar una declaración "Dónde" utilizando Expression<Func<T,bool>>métodos de interceptor. Encontré esto decepcionante. Nuestra aplicación actual utiliza los servicios RIA y creo que realmente necesitamos la capacidad de controlar la lógica IQueryable. Espero estar equivocado en esto y me estoy perdiendo algo
Además, WCF Data Services tampoco es totalmente compatible con todos los operadores LINQ. Sin embargo, todavía admite más que WebApi.
¿Qué pasa con WebApi ???
- Me gusta el control sobre Http Request / Response
- Es fácil de seguir (aprovechando los patrones MVC). Estoy seguro de que vendrán más herramientas.
A partir de ahora (a mi entender), no hay soporte de "Contexto de datos" en el cliente (es decir, Silverlight, código del lado del servidor ASP.NET, etc.), porque WebApi no se trata realmente de modelos de datos de entidad como WCF Data Services / OData es. Puede exponer colecciones de objetos modelo utilizando IQueryable / IEnumerable, pero no hay "propiedades de navegación" de clave principal / clave externa (es decir, facturas de cliente) para usar una vez que las entidades se cargan en el cliente, porque no hay "contexto de datos" que los carga de forma asincrónica (o en una llamada usando $ expand) y gestiona los cambios. No tiene una "representación" generada por código de su modelo de datos de entidad en el cliente, como lo hace en los servicios RIA o los servicios de datos WCF. No estoy diciendo que no pueda / no tenga modelos en el cliente que representen sus datos, pero ha rellenado manualmente los Datos y gestiona qué "facturas" se deben establecer con cada "cliente" una vez que se recuperan a través de la Web. Esto puede resultar complicado, especialmente con todo lo relacionado con Async. No sabe qué llamadas volverán primero. Esto puede ser difícil de explicar aquí, pero solo lea sobre el tema "Contexto de datos" en Servicios RIA oServicios de datos WCF . Entonces, cuando se trata de aplicaciones de línea de negocio, este es un problema importante para mí. Esto se basa principalmente en la productividad y la mantenibilidad. Puede crear aplicaciones de forma obvia sin un contexto de datos. Simplemente facilita las cosas, especialmente en Silverlight, WPF y ahora Windows 8 Metro. Tener Entidades relacionales cargadas en la memoria de forma asincrónica y tener Two-Binding es realmente agradable.
Dicho esto, ¿significa esto que algún día WebApi podrá admitir un "contexto de datos" en el cliente? Creo que podría. Además, con más herramientas, un proyecto de Visual Studio podría generar todos sus métodos CRUD basados en un esquema de base de datos (o Entity Framework).
Además, sé que solo menciono .NET a .NET Frameworks cuando se trata de trabajar con WCF Data Services o WebApi, pero soy muy consciente de que HTML / JS también es un actor importante. Solo estaba mencionando los beneficios que encontré al tratar con una interfaz de usuario de Silverlight, o un código del lado del servidor ASP.NET, etc. Creo que con la llegada de "IndexedDB" en HTML5 / JavaScript que tener un "Contexto de datos" y un El marco LINQ en JavaScript también podría estar disponible, facilitando aún más la capacidad de consultar los Servicios OData desde JavaScript (puede usar DataJS hoy con OData). Además, usar KnockoutJS para admitir MVVM y Binding en HTML / JS también lo hará muy sencillo :)
Actualmente estoy investigando qué plataforma usar. Me encantaría usar cualquiera de las dos, pero tiendo a inclinarme hacia OData en función del hecho de que mi próxima aplicación se trata principalmente de Analytics (solo lectura) y quiero una API RESTful rica y expresiva. Creo que OData + WCF Data Services me da eso porque WebApi solo admite $ take, $ skip, $ filter, $ orderby sobre Colecciones. NO admite Proyecciones, Incluye ($ expandir), etc. No tengo muchas "Actualizaciones / Eliminaciones / Inserciones" y nuestros Datos son bastante relacionales.
Espero que otros se unan a la discusión y expresen sus opiniones. Todavía estoy decidiendo y me encantaría escuchar otras opiniones. Realmente creo que ambos son frameworks son geniales. Me pregunto si tiene que elegir siquiera, ¿por qué no usar ambos si es necesario? Desde el cliente, todo se trata de crear llamadas REST de todos modos. Solo un pensamiento :)