and - WCF Data Services(OData) Vs ASP.NET Web API
web api rest c# (8)
Creemos que Web API proporciona la plataforma adecuada para los servicios de OData en el futuro y, como tal, invertirá principalmente en esa plataforma para las pilas de servidores OData. Por supuesto, continuaremos colocando recursos significativos en las bibliotecas y clientes principales de OData, pero planeamos reducir la inversión en Servicios de datos WCF como una pila para crear servicios OData.
Entonces, parece que todo está lo suficientemente claro
Estoy diseñando una aplicación distribuida que consistirá en servicios RESTful y una variedad de clientes (Silverlight, iOS, Windows Phone 7, etc.). En este momento estoy determinando qué tecnología debería utilizar para implementar mis servicios, WCF Data Services (OData) o la nueva ASP.NET Web API que está saliendo con ASP.NET MVC 4.
He visto algunas presentaciones en línea sobre cada una de ellas y en este momento me estoy inclinando hacia WCF Data Services principalmente debido a los mecanismos de filtrado incorporados en el URI y la capacidad nativa de hipermedia. El único inconveniente que puedo ver es la verbosidad de la especificación de Atom Pub en oposición a 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 sobre WCF Data Services?
Actualmente existen otras diferencias importantes entre WebApi y WCF Data Services, que nadie parece mencionar. Desearí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 al decir "MS está respaldando WebApi", en el sentido de que no respaldan a OData. IMO, están respaldando ambos y actualmente existe una superposición mínima. Windows Azure Data Market expone sus datos utilizando OData, Azure Table Storage usa OData, SharePoint 2010 permite las consultas de 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 crear API Web rígidas que se volvían poco manejables y requerían cambios constantes cuando una IU quería 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" expresiones LINQ y páselos como los parámetros y vuelva a hidratarlos en 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 OData permite y no quiero usar mi propio "truco" de una solución.
Es como exponer "TRANSACT SQL" sin la necesidad de una cadena de conexión DB. Simplemente proporcione una Url y ¡Whoala! Comience a consultar. Por supuesto, tanto WebApi como WCF Data Services son compatibles con Autenticación / Autorización, por lo que puede controlar el acceso, agregar declaraciones "Dónde" adicionales basadas en roles u otra configuración de datos. Prefiero hacer esto en mi Web Api Layer que en SQL (como construir vistas o almacenar los procesos). Y ahora que las Aplicaciones pueden generar consultas por sí mismas, verá que las herramientas Ad-Hoc y de Informes de BI comienzan a aprovechar OData y les permiten a los Usuarios definir sus propios resultados. No depender de Informes estáticos donde tienen un control mínimo.
Al desarrollar en Silverlight, Windows 8 Metro o ASP.NET (MVC, WebForms, etc.), puede simplemente agregar una "Referencia de servicio" en Visual Studio al Servicio de datos WCF y rápidamente comenzar a usar LINQ para consultar datos Y usted obtiene una "Contexto de datos" en el cliente, lo que significa que realiza un seguimiento de los cambios y le permite "enviar" los cambios de forma atómica al servidor. Esto muy similar a los servicios de RIA para Silverlight. Hubiera utilizado WCF Data Services en lugar de RIA Services, pero en ese momento no admitía DataAnnotations ni Actions, pero ahora sí :) WCF Data Services tiene otra ventaja sobre RIA Services, que es la capacidad de realizar "Projections" 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" en el cliente es excelente cuando se trata de aplicaciones de línea de negocio.
Entonces, WCF Data Services es excelente si tiene datos con relaciones, especialmente si está usando SQL Server y Entity Framework. Rápidamente podrá exponer Queryable Data + Actions (llamadas para invocar operaciones, es decir, flujos de trabajo, procesos en segundo plano) sobre REST con muy poco código. WCF Data Services acaba de ser actualizado. Lanzamiento nuevo lanzamiento. Echa un vistazo a todas las nuevas funcionalidades.
La desventaja de WCF Data Services es el "control" que pierde sobre la pila HTTP. Descubrí que el mayor defecto estaba en los métodos IQueryable<T> que devuelven colecciones. A diferencia de RIA Services 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 y cuando devuelva IQueryable<T> . En WCF Data Services, SOLAMENTE tiene acceso para anexar una instrucción "Where" utilizando los métodos Expression<Func<T,bool>> interceptor. Encontré esto decepcionante. Nuestra aplicación actual usa RIA Services y creo que realmente necesitamos la capacidad de controlar la lógica de IQueryable. Espero estar equivocado en esto y me falta algo
Además, WCF Data Services aún NO es totalmente compatible con todos los operadores LINQ. Aún así es compatible con más de WebApi.
¿Qué hay de 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 es realmente acerca de los modelos de datos de la entidad como WCF Data Services / OData es. Puede exponer colecciones de objetos modelo utilizando IQueryable / IEnumerable, pero no hay ninguna clave principal / clave extranjera "Propiedades de navegación" (es decir, facturas de cliente) para usar una vez que las entidades se cargan en el cliente, porque no hay un "contexto de datos" que los carga asincrónicamente (o en una llamada usando $ expand), y administra 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 puede / no tiene Modelos en el Cliente que representan sus Datos, pero ha llenado manualmente los Datos y administra qué "facturas" deben establecerse con cada "cliente" una vez que se recuperan. La web. Esto puede ser complicado, especialmente con todo lo relacionado con Async. No sabes qué llamadas volverán primero. Esto puede ser difícil de explicar aquí, pero solo lea sobre el "Contexto de datos" en RIA Services o WCF Data Services . Así que 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. Puedes construir obstructivamente aplicaciones sin un contexto de datos. Simplemente facilita las cosas, especialmente en Silverlight, WPF y ahora en Windows 8 Metro. Tener entidades relacionales cargadas en la memoria de forma asincrónica y tener dos enlaces es realmente bueno tener.
Habiendo dicho eso, ¿significa esto algún día que WebApi pueda soportar 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 estoy mencionando .NET a .NET Frameworks cuando se trata de trabajar con WCF Data Services o WebApi, pero estoy muy consciente de que HTML / JS también es un jugador importante. Acabo de mencionar los beneficios que he encontrado al tratar con una interfaz de usuario de Silverlight, o un código de ASP.NET Server-Side, etc. Creo que con el advenimiento de "IndexedDB" en HTML5 / JavaScript que tiene un "Contexto de datos" y una El marco de LINQ en JavaScript también podría estar disponible, haciendo que la posibilidad de consultar los servicios de OData sea aún más fácil desde JavaScript (puede usar DataJS hoy con OData). Además, usar KnockoutJS para admitir MVVM y Binding en HTML / JS también hará que sea más fácil :)
Actualmente estoy investigando qué plataforma usar. Me encantaría usar cualquiera de los dos, pero tiendo a inclinarme hacia OData en base al hecho de que mi próxima Aplicación es principalmente sobre Analítica (solo lectura) y quiero una APT RESTful expresiva y rica. Creo que OData + WCF Data Services me lo da porque WebApi solo admite $ take, $ skip, $ filter, $ orderby sobre Collections. NO admite Proyecciones, Incluye ($ expand), 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 marcos geniales. Me pregunto si tienes que elegir, ¿por qué no utilizar ambos si es necesario? Desde el cliente, todo se trata de construir llamadas REST de todos modos. Solo un pensamiento :)
Devaron dio la revisión más informativa de WCF vs Web Api que todavía tengo que encontrar. Gracias. Ahora que WCF es demasiado complejo, diré que la complejidad no es automáticamente negativa. Estará agradecido por el respiro que le brinda en el futuro. El desafío, como siempre, con las herramientas de Microsoft es que no sabemos ni controlamos ese futuro. Esperemos que Microsoft termine con un sistema más unificado y que permanezca por unos años.
También tengo un gran sistema para construir, y me enfatiza que el camino no está más claro. Planeo esperar un par de meses más mientras todo esto se resuelve. Y personalmente estoy apoyando datajs (también echa un vistazo a JayData)
En otras palabras :
Si está buscando exponer rápidamente un modelo de datos (EDM o de otro tipo) 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 construyes una API y simplemente quieres exponer algunos recursos (y lógica) utilizando la sintaxis o el formato de la consulta OData, entonces la API web de ASP.NET es probablemente el mejor lugar para comenzar.
Esta es la respuesta de TL; DR a esta pregunta.
WCF es la navaja suiza del destornillador de la API WEB para la comunicación y transferencia de datos: WCF puede hacer todo lo que la API WEB puede hacer, pero, si necesita más (p. Ej., Utilizando el protocolo TCP), WCF es el camino a seguir.
Aquí hay una gran comparación .
API WEB
La razón número uno para usar WEB API es que es liviana. Esto significa que es más fácil de implementar, más fácil de aprender, más fácil de mantener, etc. Está específicamente diseñado para la Web, que necesita servicios web RESTful a través de HTTP. Hace esto y lo hace bien. Si, esto es todo lo que necesita, WEB API es probablemente el camino a seguir.
Además, es de código abierto (si te importa)
WCF
WCF simplemente hace mucho más que API WEB: admite múltiples protocolos de transferencia, múltiples patrones de intercambio (WEB API 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 el consumo de API RESTful consultables e interoperables de una manera simple y estándar. fuente: http://www.odata.org/
En otras palabras, alto nivel, solo está estandarizando una gramática específica para las solicitudes HTTP RESTful. Lo cual proporcionará los mismos beneficios que cualquier protocolo. Y a partir de al menos 2013 tanto WCF como API WEB permiten el uso de OData. Entonces, probablemente no vale la pena preocuparse por OData.
Esta es una pregunta subjetiva, así que aquí hay una respuesta subjetiva. IMO, WCF tiene demasiada sobrecarga para servicios RESTful simples. Web API, por otro lado, fue diseñado específicamente para servicios RESTful.
Estoy de acuerdo con Dave Ward en esto . Mira su blog para más información.
Durante mucho tiempo resistí la presión de pasar de ASMX a WCF en los proyectos de WebForms, porque aceptar la complejidad de WCF principalmente solo me recompensaba con una serialización JSON menos flexible. Por el contrario, comencé a convertir algunos de mis proyectos de ASMX a API web, y me ha complacido la facilidad con la que la API web reemplaza a ASMX.
Creo que Microsoft finalmente encontró un buen equilibrio entre la simplicidad de ASMX y el poder de WCF con Web API.
Simplemente dígalo de esta manera en términos simples, retroceda desde el protocolo subyacente y mire esto desde la perspectiva del desarrollador / usuario. La API web es el marco de descanso basado en HTTP de primera clase de Microsoft, no WCF. Eso significa que falta cualquier característica de Rest, especificaciones, que se agregarán a la API Web y no necesariamente a WCF.
Sí, puede implementarlos usted mismo en WCF, pero como dice la oración, debe implementarlos usted mismo.
Solo como un ejemplo, la implementación de una autenticación de 2 factores para una API web lleva menos de 15 minutos utilizando OWIN, que es principalmente un paquete nuget de Autenticación / Autorización que comenzó como un proyecto de código abierto.
Cuando utiliza una pila de tecnología, hace una gran diferencia usar la pila de primera clase para Microsoft. Incluso tendría innumerables MS publicado código de muestra y proyectos en Github que puede simplemente copiar y hacer una ventaja en su propio proyecto. Marca la diferencia en todos los niveles, documentación, muestras de código, conjunto de características, soporte, aplicaciones de ayuda, lo que sea.
Así que mi simple consejo para usted, si desea construir aplicaciones basadas en Restfull HTTP, use la API web (o ASP.NET Core para la portabilidad) y realmente se mantenga alejado de WCF. Si el protocolo no es HTTP y realmente no puede ser HTTP, use WCF.
Tanto Web API como WCF Data Services son compatibles con OData de fábrica. Con WCF Data Services (WCFDS), es automático. Con Web API, devuelva IQueryable desde su controlador y etiquete el método con [Queryable] . Esto te dará la funcionalidad $filter que hablabas. Y si lo hace de esta manera, ambos pueden manejar JSON en la respuesta automáticamente al poner accept=application/json en el encabezado de la solicitud. El OData de WCFDS admite algunas palabras clave más de OData que la API web (aunque solo se me ocurre la palabra clave $expand ), pero estoy seguro de que el tiempo lo solucionará.
Tanto los clientes .NET como las páginas HTML pueden invocar fácilmente estas dos alternativas, pero si le gusta LINQ y está creando clientes .NET, WCFDS se puede agregar a su proyecto como referencia de servicio. Esto le permite omitir todos los negocios HTTP por completo y consultar directamente las colecciones.
La conclusión es que no hay nada que le impida poner archivos .svc en su proyecto ASP.Net MVC. No es una propuesta de uno u otro. Agregar servicios de datos a su servidor le ahorrará la necesidad de escribir muchos controladores, pero no le impide escribir controladores adicionales si lo desea.