A una gran cantidad de desarrolladores de software se nos ha planteado el reto de realizar una capa de servicios o adaptar nuestra aplicación a una capa de servicios, teniendo que dar respuesta en primera instancia a la siguiente pregunta: ¿Qué tecnología debo utilizar para dar solución a este problema?

Lo primero que aconsejaría es comprender bien el problema al que nos enfrentamos para saber dar solución al mismo de la manera más eficiente y correcta posible, haciendo uso de las herramientas que tenemos a nuestra disposición. No debemos decantarnos por una u otra opción por ser la más utilizada o por ser la tecnología de moda, sino por ser la que mejor se adapte y dé solución al problema planteado.

A veces he tenido que enfrentarme a esta pregunta e incluso defender el uso de ciertas tecnologías para la creación de una capa de servicios ante algún cliente reacio al cambio que se amparaba en la necesidad de aprender a usar una nueva tecnología para resolver un problema que podía ser solventado con una tecnología ya consolidada y existente.

El objetivo final de este artículo es, por tanto, ayudar a la toma de una decisión al respecto de manera rápida y certera, centrándonos en alternativas de tecnologías Microsoft.

Indagar e investigar sobre tecnologías como WCF o Web API desde la perspectiva del problema a resolver me ha permitido confeccionar un pequeño esquema mental que me sirve de apoyo para dar una mejor y más rápida respuesta concierne a este tipo de asuntos.

A saber que WCF (Windows Communication Foundation) es un framework para la creación de aplicaciones orientadas a servicios. Originalmente fue concebido para crear servicios basados en SOAP y otros bindings relacionados.

Respecto a la tecnología Web API, es una alternativa (de peso ligero a WCF) para construir servicios REST que pueden ser consumidos por diferentes clientes.

 

Comparativa entre WCF y Web API

A continuación, se comparan algunas de las características principales de ambas tecnologías:

WCF	WEB API
Ideado para construir: Servicios SOAP que devolvieran datos en XML Servicios seguros, fiables y transaccionales que pudieran soportar mensajería y ser accesibles a través de una serie de transportes	Fue pensado para construir: Servicios REST a través de HTTP Servicios orientados a los recursos a través de HTTP, pudiendo aprovechar las características completas del protocolo como: Control de versiones Control de caché en los navegadores Control de la concurrencia mediante Etags
Presenta comunicación dúplex	Es ligero y se adapta bien a dispositivos que han limitado el ancho de banda como smarthphones, tablets…
Es más versátil que Web API, ya que puede utilizar más protocolos:  TCP, HTTP, HTTPS, Named Pipes, MSMQ…	Permite exponer servicios en una amplia gama de clientes: navegadores web, tablets, móviles…
Tiene una amplia configuración y, por lo tanto, una mayor curva de aprendizaje	Más fácil y simple de usar que WCF

Tabla 1: Tabla comparativa de características de tecnologías: WCF y WebAPI

Una vez vistas de forma muy genérica las características de ambas tecnologías, pasamos a adentrarnos en el punto que provoca mayor debate a la hora de decantarse por una u otra tecnología para la resolución de un determinado problema.

Se ha mencionado que Web API nació como alternativa de peso ligero a WCF para la construcción de servicios REST, pero es el WCF como modelo unificado de Microsoft para compilar aplicaciones orientadas a servicios lo que proporciona cierta compatibilidad para escribir servicios de tipo REST. Sin embargo, esta compatibilidad para REST en Web API es más completa, ya que el sino de su existencia es precisamente éste, y todas las futuras mejoras de las características de REST se llevarán a cabo en Web API.

A continuación, para los no iniciados en el mundo de los servicios, se muestra un ejemplo gráfico de un servicio que presenta las diferencias respecto a la codificación de ambas tecnologías (en este caso en lenguaje C#), enseñándose prácticamente el mismo servicio de dos maneras diferentes. Ambos son accesibles a través de HTTP / REST e implementan peticiones GET y POST:

• GET: Solicitud que devuelve una cadena con la hora actual
• POST: Solicitud para aceptar datos y devolver los mismos datos en un stream

 

Como se ha mencionado al comienzo de este artículo, dependiendo del problema a resolver, tendremos que tomar distintas decisiones de uso. Si ya tenemos un servicio WCF y queremos exponer extremos de REST adicionales, la recomendación sería utilizar WCF y WebHttpBinding.

WCF para REST soporta verbos como GET y POST, haciendo uso de los atributos [WebGet] y [WebInvoke] respectivamente. Para pasar datos a través de [WebGet] será necesario realizar alguna configuración adicional, como por ejemplo especificar la UriTemplate.

WCF para REST soporta formatos de datos como XML, JSON y ATOM.

 

WCF vs. WebAPI: Conclusiones

En función del escenario (aunque seguro que existen más que los que expondré a continuación), mi recomendación de uso sería:

WCF	WEB API
Escenarios especiales como mensajería one-way, colas de mensajes y comunicación dúplex	Servicios orientados a recursos a través de HTTP (URIs, request/response headers, control de caché para navegadores, control de versiones, concurrencia utilizando ETags, diferentes formatos de contenido)
Cuando se quiere hacer uso de canales de transporte rápidos como TCP, Named Pipes y UDP (WCF 4.5)	Se quieren exponer servicios para una amplia gama de clientes: navegadores, smarthphones, tablets…

Tabla 2: Algunos escenarios para la elección entre tecnología WCF y Web API

En definitiva, debemos entender bien el problema y dar solución al mismo haciendo uso de las herramientas más apropiadas de las que dispongamos para ese caso.

 

Si queréis comentarnos lo que sea podéis hacerlo en info@kabel.es

También podéis seguirnos en Twitter y LinkedIn.