Servicios de datos WCF (OData) Vs ASP.NET Web API

Estoy diseñando una aplicación distribuida que constará de servicios RESTful y una variedad de clientes (Silverlight, iOS, Windows Phone 7, etc.). En este momento estoy determinando qué tecnología debo usar para implementar mis servicios, WCF Data Services (OData) o la nueva API web ASP.NET que se lanzará con ASP.NET MVC 4.

He visto algunas presentaciones en línea sobre cada uno y en este momento me estoy inclinando hacia WCF Data Services principalmente debido a los mecanismos de filtrado integrados en la URI y la capacidad hipermedia nativa. El único inconveniente que puedo ver es la verbosidad de la especificación Atom Pub en comparación con POX.

¿Hay algo que deba saber sobre estas dos tecnologías antes de tomar una decisión? ¿Por qué alguien elegiría ASP.NET Web API en lugar de WCF Data Services?

Esta es una pregunta subjetiva, así que aquí tienes una respuesta subjetiva. En mi opinión, WCF tiene demasiada sobrecarga para servicios RESTful simples. La API web, por otro lado, fue diseñada específicamente para servicios RESTful.

Estoy de acuerdo con Dave Ward en esto . Consulte su blog para obtener más información.

Durante mucho tiempo me he resistido a la presión para pasar de ASMX a WCF en proyectos de WebForms, porque aceptar la complejidad de WCF principalmente solo me recompensa con una serialización JSON menos flexible. Por el contrario, comencé a convertir algunos de mis proyectos de ASMX a Web API y me ha complacido la facilidad con la que Web API reemplaza a ASMX.

Creo que Microsoft finalmente ha encontrado un buen equilibrio entre la simplicidad de ASMX y el poder de WCF con Web API.

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 ???

1. Me gusta el control sobre Http Request / Response
2. 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 :)

Creemos que Web API proporciona la plataforma adecuada para los servicios de OData en el futuro y, como tal, invertiremos principalmente en esa plataforma para pilas de servidores OData. Por supuesto, continuaremos poniendo recursos significativos en las bibliotecas centrales y el cliente de OData, pero planeamos reducir la inversión en WCF Data Services como una pila para crear servicios OData.

Blog del equipo de OData

Entonces, parece que ahora todo está lo suficientemente claro

Tanto la API web como los servicios de datos WCF admiten OData de forma inmediata. Con WCF Data Services (WCFDS), es automático. Con Web API, regrese IQueryablede su controlador y etiquete el método con [Queryable]. Esto le dará la $filterfuncionalidad de la que estaba hablando. Y si lo hace de esta manera, ambos pueden manejar JSON en la respuesta automáticamente colocando accept=application/jsonel encabezado de la solicitud. OData de WCFDS admite algunas palabras clave OData más que la API web (aunque solo se me $expandocurre la palabra clave), pero estoy seguro de que el tiempo solucionará esto.

Tanto los clientes .NET como las páginas HTML pueden llamar a ambas alternativas fácilmente, pero si le gusta LINQ y está creando clientes .NET, puede agregar WCFDS a su proyecto como referencia de servicio. Esto le permite omitir todo el negocio HTTP por completo y consultar directamente las colecciones.

La conclusión es que no hay nada que le impida colocar archivos .svc en su proyecto ASP.Net MVC. No es una propuesta de una u otra. Agregar servicios de datos a su servidor le ahorrará la necesidad de escribir muchos controladores, pero no le impedirá escribir controladores adicionales si lo desea.

En otras palabras :

Si está buscando exponer un modelo de datos (EDM o de otro tipo) rápidamente y no necesita mucho código o lógica comercial, WCF Data Services lo hace REALMENTE fácil y sería un buen punto de partida.

Si está creando una API y simplemente desea exponer algunos recursos (y lógica) utilizando la sintaxis o el formato de consulta de OData, entonces ASP.NET Web API es probablemente el mejor lugar para comenzar.

http://mattmilner.com/Milner/Blog/post/2013/04/02/WCF-Data-Services-and-Web-API-with-OData;-choices-choices.aspx

Devaron dio la revisión más informativa de WCF vs Web Api que todavía tengo que encontrar. Gracias. Ahora, hasta el punto de que WCF es demasiado complejo, diré que la complejidad no es automáticamente un negativo. Estarás agradecido por el espacio para respirar que te brinda en el futuro. El desafío, como siempre, con las herramientas de Microsoft es que no conocemos ni controlamos ese futuro. Esperemos que Microsoft termine con un sistema más unificado y que se mantenga por unos años.

También tengo un gran sistema para construir, y me estresa que el camino no esté más claro. Planeo esperar un par de meses más mientras todo esto se arregla. Y personalmente estoy enraizando para datajs (también echa un vistazo a JayData)

Póngalo de esta manera en términos más simples, aléjese del protocolo subyacente y mire esto desde la perspectiva del desarrollador / usuario. Web API es el Rest Framework basado en HTTP de primera clase de Microsoft, no WCF. Eso significa que las características y especificaciones de Rest que falten se agregarán a la tubería de API web y no necesariamente a WCF.

Sí, puede implementarlos usted mismo en WCF, pero como dice en la oración, debe implementarlos usted mismo.

Solo como ejemplo, la implementación de una autenticación de 2 factores para una API web lleva menos de 15 minutos usando OWIN, que es un paquete nuget de autenticación / autorización que comenzó como un proyecto de código abierto.

Cuando usa una pila de tecnología, hace una gran diferencia usar la pila de primera clase para Microsoft. Incluso tendría innumerables proyectos y códigos de muestra publicados en MS en Github que simplemente puede copiar y comenzar con ventaja en su propio proyecto. Marca la diferencia en todos los niveles, documentación, ejemplos de código, conjunto de características, soporte, api de ayuda, lo que sea.

Entonces, mi simple consejo para usted, si desea crear aplicaciones basadas en HTTP Restfull, use la API web (o ASP.NET Core para la portabilidad) y realmente manténgase alejado de WCF. Si el protocolo no es HTTP y realmente no puede ser HTTP, utilice WCF.

Esta es la respuesta de TL; DR a esta pregunta.

WCF es la navaja suiza del destornillador de WEB API para la comunicación y transferencia de datos: WCF puede hacer todo lo que puede hacer WEB API, pero, si necesita más (por ejemplo, usando el protocolo TCP), WCF es el camino a seguir.

He aquí una gran comparación .

API WEB

La razón número uno para usar la API WEB es que es liviana. Esto significa que es más simple de implementar, más fácil de aprender, más fácil de mantener, etc. Está diseñado específicamente para la Web, que necesita servicios web RESTful sobre HTTP. Hace esto y lo hace bien. Si esto es todo lo que necesita, la API WEB es probablemente el camino a seguir.

Además, es de código abierto (si te importa)

WCF

WCF solo hace mucho más que la API WEB: admite múltiples protocolos de transferencia, múltiples patrones de intercambio (la API WEB requiere integración con SignalR o Web Sockets), los servicios SOAP se pueden describir en WSDL, tiene características de seguridad adicionales y más. Vaya con WCF si necesita esta funcionalidad adicional.

OData

OData es simplemente

Un protocolo abierto para permitir la creación y consumo de APIs RESTful consultables e interoperables de forma sencilla y estándar. fuente: http://www.odata.org/

En otras palabras, de alto nivel, solo está estandarizando una gramática específica para las solicitudes HTTP RESTful. Lo que proporcionará los mismos beneficios que cualquier protocolo. Y a partir de al menos 2013, tanto WCF como WEB API permiten el uso de OData. Por lo tanto, probablemente no valga la pena preocuparse por OData.