c# - and - WCF vs ASP.NET Web API

web api c# (11)

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

He luchado bastante para entender todas las configuraciones en el archivo de configuración.
No estoy convencido del medio ambiente, pero parece que puedes hacer cosas increíbles con él.

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

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

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

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

¿Por qué estoy respondiendo:

Tomé mucho tiempo para entender la diferencia entre estas dos tecnologías. Pondré todos esos puntos aquí que pienso "Si tuve estos puntos en el momento en que me preguntaba por ahí en busca de esta respuesta, entonces he decidido muy pronto en la selección de la 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 existen dos estilos / estándares para crear servicios web: REST (Representational State Transfer) y SOAP / WSDL. El 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 utilizan formatos de mensajes más pequeños (como JSON). Como resultado, los servicios HTTP basados en REST ahora son el estándar para escribir servicios que se dirigen estrictamente a la web.

Vamos a definir el propósito de la API web de 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 se basaba 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 respaldar 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:

Comunicarse 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 de comunicación (como TCP / IP). Los desarrolladores de servicios se encontraron haciendo las mismas elecciones que intentaban evitar. Ahora tendrían que elegir entre crear servicios internos eficientes y poder tener el acceso amplio que se encuentra en Internet. Y, si tuvieran que admitir ambos, podrían tener que crear varias versiones de su servicio o, al menos, proxies 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 el momento del diseño o después de la implementación). Cada punto final indica cómo el servicio puede admitir un cliente llamante: a través de la Web, a través de la comunicación remota, a través de Microsoft Message Queue Server (MSMQ) y más. WCF le permite enfocarse en crear la funcionalidad de su servicio. Se preocupa por cómo hablar más eficientemente con los clientes que llaman. De esta manera, un solo servicio WCF puede admitir de manera eficiente muchos tipos diferentes de clientes.

Ejemplo de WCF:

Considera el ejemplo:

Los datos del cliente se comparten entre las aplicaciones. Cada aplicación puede estar escrita 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, mediante el uso de WCF, puede configurar los puntos finales del servicio para que funcionen de la manera que tenga sentido para el cliente que realiza la llamada. La figura muestra el ejemplo de antes 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 de ASP.NET se han convertido en el estándar para crear servicios web. Estos servicios ofrecen un enfoque sencillo y directo para los desarrolladores de 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 dirigidos estrictamente a HTTP , la API web de 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 también pueden usarse en la Web a través de diferentes configuraciones de máquina a máquina. Si, sin embargo, necesita escribir una aplicación que se comunique a través de TCP / IP cuando esté conectado a la red local Red y funciona a través de HTTP cuando está fuera de la red, WCF es su respuesta .

Tenga cuidado:

Los desarrolladores web a menudo consideran que WCF es 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 de ASP.NET.

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

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

Con wcf podemos configurar y exponer el mismo servicio de soporte para múltiples puntos finales como tcp, http.if, si desea que su servicio se base solo en http, será mejor utilizar la 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 soporta servicios de descanso. Si tiene una limitación de .Net framework 3.5, entonces su opción es wcf.

Desde el uso de ambos hasta ahora, he encontrado muchas diferencias entre WCF y la API web. Ambas tecnologías se combinan bien en diferentes escenarios diferentes. Por lo tanto, no es posible decir cuál es mejor, esto depende de la configuración y el escenario.

Nota: Los datos no son solo mi opinión, sino que también se recopilan de otro sitio web oficial.

En los escenarios que se enumeran a continuación, debe ir para WCF:

Si necesita enviar datos en protocolos como TCP, MSMQ o MIME
Si el cliente consumidor solo sabe como consumir mensajes SOAP

WEB API es un marco para el desarrollo de servicios RESTful / HTTP.

Hay tantos clientes que no entienden SOAP como los navegadores, HTML5, en esos casos, las API de 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 de cuerpo del mensaje y el cuerpo HTTP pueden especificar cualquier tipo de contenido, como HTML, no solo XML como servicios SOAP.

Hablando de negocios, WebApi carece de un WSDL, por lo que los desarrolladores deben documentar todo manualmente. Y si, por ejemplo, la operación de 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 su más ligero que WCF.

Hay una comparación en MSDN sobre esto

WCF y API web de ASP.NET

Para mí, la elección fue sobre quiénes son los clientes y dónde están ubicados.

Dentro de la red de la empresa y los clientes basados en .NET: 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 la API web con REST

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 los servicios basados en SOAP. Para servicios RESTful o RPCish más simples (piense en clientes como jQuery) ASP.NET Web API debería ser una buena opción.

Para nosotros, WCF se utiliza para SOAP y API web para REST. Ojalá la API web sea compatible con SOAP también. No estamos utilizando las características avanzadas de WCF. Aquí está la comparación de msdn.microsoft.com/en-us/library/jj823172.aspx :

Respecto a la declaración "Ausencia de WSDL de WebApi" hay varias formas de generar un 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.

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