Pasé unos meses tratando de comprender los conceptos detrás de WCF y recientemente desarrollé mi primera aplicación de servicio WCF.

Me ha costado bastante entender todas las configuraciones en el archivo de configuración.
No estoy convencido del entorno, pero parece que puedes hacer cosas increíbles con él.

El otro día descubrí que Microsoft ha lanzado una nueva cosa llamada API web ASP.NET .

Por lo que puedo leer, es un marco RESTful , muy fácil de usar e implementar.

Ahora, estoy tratando de descubrir cuáles son las principales diferencias entre los 2 marcos y si debería intentar convertir mi antigua aplicación de servicio WCF con la nueva API.

¿Podría alguien, por favor, ayudarme a comprender las diferencias y el uso de cada uno?

La nueva API web de ASP.NET es una continuación del proyecto anterior de la API web de WCF (aunque algunos de los conceptos han cambiado ).

WCF se creó originalmente para habilitar servicios basados ​​en SOAP. Para servicios RESTful o RPCish más simples (piense en clientes como jQuery), la API web ASP.NET debería ser una buena opción.

Para nosotros, WCF se utiliza para SOAP y API web para REST. Deseo que la API web sea compatible con SOAP también. No estamos utilizando funciones avanzadas de WCF. Aquí hay una comparación de MSDN :

ASP.net Web API tiene que ver con HTTP y REST GET, POST, PUT, DELETE basado en el conocido estilo de programación ASP.net MVC y JSON retornable; API web es para todo el proceso ligero y componentes basados ​​en HTTP puro. Para que uno siga adelante con WCF, incluso para el servicio web simple o más simple, traerá todo el equipaje extra. Para un servicio simple y liviano para llamadas dinámicas o ajax, siempre WebApi simplemente resuelve la necesidad. Esto complementa o ayuda en paralelo al ASP.net MVC.

Mira el podcast: Hanselminutes Podcast 264 - Este no es el WCF de tu padre - Todo sobre el WebAPI con Glenn Block por Scott Hanselman para más información.

En los escenarios enumerados a continuación, debe elegir WCF:

1. Si necesita enviar datos en protocolos como TCP, MSMQ o MIME
2. Si el cliente consumidor solo sabe cómo consumir mensajes SOAP

WEB API es un marco para desarrollar servicios RESTful / HTTP.

Hay tantos clientes que no entienden SOAP como los navegadores, HTML5, en esos casos, las API WEB son una buena opción.

El encabezado de servicios HTTP especifica cómo proteger el servicio, cómo almacenar en caché la información, el tipo del cuerpo del mensaje y el cuerpo HTTP puede especificar cualquier tipo de contenido como HTML, no solo XML como servicios SOAP.

Desde que usé ambos hasta ahora, he encontrado muchas diferencias entre WCF y API web. Ambas pilas de tecnología se adaptan bien a diferentes escenarios, por lo que no es posible decir cuál es mejor, esto depende de la configuración y el escenario.

Properties              ASP.Net Web API                         WCF
--------------------------------------------------------------------------------------------------
End point (mainly)      Http based                              SOAP based
Service Type            Front End                               Back-end
Support                 caching, compression, versioning        No
Framework               ASP.net                                 WCF
Orientation             Resource Oriented                       Service Oriented
Transports              http                                    http, tcp, MSMQ, Named pipe
Message pattern         Request reply                           request Reply, one way, duplex
Configuration overhead  Less                                    Much
Security                lesser than WCF (web standard security) Very high (WS-I standard)
Hosting                 IIS                                     IIS, Windows Service, Self hosting
Performance             Fast                                    A bit slower than Web API
In use from             .NET 4.0                                .NET 3.5

Nota: Los datos no son solo mi opinión, también se recopilan de otros sitios web oficiales.

WCF le dará mucho de la caja, ni siquiera es comparable a nada. A menos que desee realizar su propia implementación de (por nombrar algunos) autenticación, autorización, cifrado, colas, aceleración, mensajería confiable, registro, sesiones, etc. WCF no es [solo] servicios web; WCF es una plataforma de desarrollo para SOA.

Por qué estoy respondiendo:

Me tomó mucho tiempo entender la diferencia entre estas dos tecnologías. Pondré todos esos puntos aquí que pienso "Si tenía estos puntos en el momento en que me preguntaba en busca de esta respuesta, entonces he decidido muy temprano al seleccionar mi tecnología requerida".

Fuente de información:

Microsoft® Visual Studio® 2015 desatado

ISBN-13: 978-0-672-33736-9 ISBN-10: 0-672-33736-3

Por qué ASP.NET Web API y WCF:

Antes de comparar las tecnologías de ASP.NET Web API y WCF, es importante comprender que en realidad hay dos estilos / estándares para crear servicios web: REST (Representational State Transfer) y SOAP / WSDL. SOAP / WSDL fue el estándar original en el que se construyeron los servicios web. Sin embargo, era difícil de usar y tenía formatos de mensajes voluminosos (como XML) que degradaban el rendimiento. Los servicios basados ​​en REST se convirtieron rápidamente en la alternativa. Son más fáciles de escribir porque aprovechan las construcciones básicas de HTTP (GET, POST, PUT, DELETE) y generalmente usan formatos de mensaje más pequeños (como JSON). Como resultado, los servicios HTTP basados ​​en REST son ahora el estándar para escribir servicios que se dirigen estrictamente a la Web.

Definamos el propósito de la API web ASP.NET

ASP.NET Web API es la tecnología de Microsoft para desarrollar servicios web HTTP basados ​​en REST. (Hace mucho tiempo reemplazó el ASMX de Microsoft, que estaba basado en SOAP / WSDL). La API web facilita la escritura de servicios robustos basados ​​en protocolos HTTP que todos los navegadores y dispositivos nativos entienden. Esto le permite crear servicios para admitir su aplicación y llamarlos desde otras aplicaciones web, tabletas, teléfonos móviles, PC y consolas de juegos. La mayoría de las aplicaciones escritas hoy para aprovechar la conexión web siempre presente utilizan los servicios HTTP de alguna manera.

Ahora definamos el propósito de WCF:

La comunicación a través de Internet no siempre es el medio más eficiente. Por ejemplo, si tanto el cliente como el servicio existen en la misma tecnología (o incluso en la misma máquina), a menudo pueden negociar un medio más eficiente para comunicarse (como TCP / IP). Los desarrolladores de servicios se encontraron tomando las mismas decisiones que intentaban evitar. Ahora tendrían que elegir entre crear servicios internos eficientes y poder tener un amplio acceso a través de Internet. Y, si tuvieran que soportar ambos, podrían tener que crear múltiples versiones de su servicio o al menos servidores proxy separados para acceder a su servicio. Este es el problema que Microsoft resolvió con WCF .

Con WCF, puede crear su servicio sin preocuparse por los límites. Luego puede dejar que WCF se preocupe por ejecutar su servicio de la manera más eficiente, dependiendo del cliente que llama. Para gestionar esta tarea, WCF utiliza el concepto de puntos finales. Su servicio puede tener múltiples puntos finales (configurados en tiempo de diseño o después de la implementación). Cada punto final indica cómo el servicio podría admitir un cliente que realiza la llamada: a través de la Web, a través de comunicación remota, a través de Microsoft Message Queue Server (MSMQ) y más. WCF le permite concentrarse en crear la funcionalidad de su servicio. Le preocupa cómo hablar de manera más eficiente con los clientes que llaman. De esta manera, un único servicio WCF puede soportar de manera eficiente muchos tipos de clientes diferentes.

Ejemplo de WCF:

Considere el ejemplo:

Los datos del cliente se comparten entre las aplicaciones. Cada aplicación puede escribirse en una plataforma diferente y puede existir en una ubicación diferente. Puede extraer la interfaz del cliente en un servicio WCF que proporciona acceso común a los datos compartidos del cliente. Esto centraliza los datos, reduce la duplicación, elimina la sincronización y simplifica la administración. Además, al usar WCF, puede configurar los puntos finales de servicio para que funcionen de la manera que tenga sentido para el cliente que realiza la llamada. La Figura muestra el ejemplo anterior con acceso centralizado a los datos del cliente en un servicio WCF.

Conclusión:

i) Cuándo elegir la API web:

No se puede negar que los servicios HTTP basados ​​en REST como los creados con la API web ASP.NET se han convertido en el estándar para crear servicios web. Estos servicios ofrecen un enfoque sencillo y directo para los desarrolladores web que crean servicios. Los desarrolladores web entienden HTTP GET y POST y, por lo tanto, se adaptan bien a este tipo de servicios. Por lo tanto, si está escribiendo servicios estrictamente dirigidos a HTTP , la API web ASP.NET es la opción lógica.

ii) Cuándo elegir WCF:

La tecnología WCF es útil cuando necesita admitir múltiples puntos finales de servicio basados ​​en diferentes protocolos y formatos de mensajes. Productos como Microsoft BizTalk aprovechan WCF para crear servicios robustos que se pueden usar en la Web también a través de diferentes configuraciones de máquina a máquina. Sin embargo, si necesita escribir una aplicación que se comunique a través de TCP / IP cuando se conecta al local red y funciona a través de HTTP cuando está fuera de la red, WCF es su respuesta .

Ten cuidado:

Los desarrolladores web a menudo ven a WCF como más difícil y complejo de desarrollar. Por lo tanto, si no prevé la necesidad de servicios multiprotocolo, es probable que se quede con la API web ASP.NET.

Hay una comparación en MSDN sobre esto

API web WCF y ASP.NET

Para mí, la elección fue ¿Quiénes son los clientes y dónde están ubicados?

Dentro de los clientes basados ​​en redes y .NET de la compañía: use WCF con enlace TCP (comunicación rápida que HTTP)

Fuera de la red de la empresa, y use diversas tecnologías como PHP, Python, etc .: use API web con REST

Hablando de negocios, WebApi carece de un WSDL, por lo que los desarrolladores deben documentar todo manualmente. Y si, por ejemplo, la operación WebApi devuelve una lista de objetos, el cliente debe crear los objetos manualmente, es decir, WebAPI es realmente propenso a errores de definiciones.

El profesional de Webapi es más ligero que WCF.

Con respecto a la declaración "WebApi carece de WSDL", hay varias formas de generar el cliente Rest. Un enfoque popular es Swagger UI / (Swashbukkle Nuget). Esto proporciona una interfaz rica para comprender el esquema de entrada y salida del punto final REST y la herramienta en línea para probar los puntos finales.

JSON LD (Json Linked Documents) es otro estándar emergente que mejorará aún más la experiencia del desarrollador REST basado en JSON al exponer el esquema JSON con una mejor semántica.

Con wcf podemos configurar y exponer el mismo soporte de servicio para múltiples puntos finales como tcp, http. Si desea que su servicio se base solo en http, será mejor usar API web. La API web tiene una configuración muy inferior en comparación con wcf y es un poco más rápida que wcf. Wcf también admite servicios tranquilos. Si tiene limitaciones de .Net framework 3.5, entonces su opción es wcf.