Servicios REST en WCF – Mucho trabajo mismo resultado

Desde que surgió WCF siempre se ha estado en constante evolución hacia lograr hacer servicios web totalmente sobre HTTP, intentando dar soporte por supuesto a los servicios RestFul y centrando su atención en todos los poderes del protocolo http para empezar a verlo como lo que es, un protocolo de aplicación.

Mucha gente se esforzó por darle el rumbo correcto a este producto, varios APIs se vieron ir y venir en CodePlex, siempre persiguiendo el mismo objetivo. Finalmente en la versión 3.5 y 4 de WCF se llego a decir que era posible la construcción de servicios RESTFul.

Personalmente nunca me han gustado los servicios WCF y no puedo decir que sea un experto en la materia, pero el hecho de tener que trabajar con tantos y tantos tipos de configuraciones en archivos .config donde no te saldrá un error de compilación si algo está mal [Siempre será una linda pantalla de error con un mensaje que nunca entiendes, y no lo niegues que es así :P], donde testear estos servicios requiere de un cliente o aplicación [WCF Test Client por ejemplo] donde por cada forma de consumo se debe teclear un nuevo EndPoint, tener que decorar con tantos atributos los métodos para tener algún tipo de funcionalidad personalizada y un gran etc. que hace que no me termine de gustar esta tecnología.

Entonces sí! Pensar en construir servicios Rest con WCF “puede llegar a ser” posible, si estás dispuesto a trabajar con todo ese gran “cascaron” que envuelve a WCF. Para la muestra un par de entradas que muestran un paso a paso de cómo construir un servicio rest haciendo uso de los vervos de http y la “negociación” de contenido. Vi este en CodeProjet y este ultimo a un compañero de BDotNet. En ellos se plantea una buena solución al problema, pero para mí sigue sin ser Rest, ¿por qué? A simple vista no se está haciendo uso de una negociación de contenido, simplemente se definen dos métodos distintos decorados de forma diferente haciendo uso del atributo WebInvoke y dejando de lado el uso de los encabezados de http. Además de cómo se muestran en los artículos se hace uso de “todo” el poder de los Bindings y Endpoints y del conocido webHttpBinding.

Esta solución no me convenció y encontré este artículo muy detallado en MSDN, la verdad no lo termine e implementar y es que es muy complejo y ¡me desgasta mucho!

Una visión más clara, ASP.NET Web API

Con la llegada de MVC 4 salió WEB API, este framework SI se pensó para la construcción de servicios sobre http, a diferencia de todas las modificaciones de WCF que desde un inicio se pensó para soportar SOAP y nada más que SOAP, la verdad no sé si se reescribió de cero [creo que no], pero si se pensó bien, muy bien como debía trabajar.

A diferencia de los WCF con WEB API no debemos preocuparnos por archivos de configuración de grandes magnitudes, ni de decorar con una gran cantidad de atributos a nuestros métodos para que trabajen con los verbos de http.

Basta con crear una nueva aplicación de ASP.NET MVC 4, y seleccionar la opción Web Api. Uno de los primeros beneficios es el método MapHttpRoute, que nos permitirá hacer uso de los verbos de http sin tener que esforzarnos como lo haríamos con un método WCF que queremos responda a un Get o a un Post.

Si consumimos este servicio, desde un navegador y vemos el cuerpo de la respuesta veremos que por defecto en IE9 nos regresa un JSON, para mí, esto ya es una ventaja 😀 ya no tenemos esos feos envolve que teníamos con SOAP. Una muestra de lo anterior:

Y en este caso nosotros tenemos una completa negociación de contenido haciendo uso del encabezado de la solicitud y sin escribir una línea de más. Así:

Como vemos WEB API incorpora todos estos beneficios de fabrica, y no tenemos que preocuparnos por construir enmarañados WCF para “simular” Y NO NIEGO QUE SE PUEDA LOGRAR, que yo no lo he logrado hacer es otra cosa, pero por ahí he oído de gente muy buena en esto de los servicios WEB que si es posible… de lo que si estoy seguro es que les toca escribir mas líneas que a mí 😛

Espero les sea de utilidad.

Hasta el próximo post.

Anuncios
Servicios REST en WCF – Mucho trabajo mismo resultado

3 comentarios en “Servicios REST en WCF – Mucho trabajo mismo resultado

  1. Camilio Escobeto dijo:

    Creo que el punto de vista no está enfocado adecuadamente, supongamos que deseas clavar un clavo y tenes una caja de herramientas muy variadita pues es posible tomar un destornillador y cogerlo del lado contrario al mango y con el mago empezar a clavar el clavo lo que es totalemente posible en determinadas condiciones, pero si en la caja de herramientas tenes un martillo pues usemos el martillo ¿no?, entonces WCF tiene una finalidad diferente a la de WEB API, tenes que entender que MSFT siempre cuando sale con nuevas cosillas hace todo lo posible para que sea aceptada muy rapido y fácil por ello WCF RESTFul. Por eso mismo es como si tu articulo fuera: Clavar clavos con un destornillador mucho trabajo mismo resultado que con un martillo. Dah!

    1. umm??.. pues igual, si quieres atornillar con un martillo(WCF) no seria lo indicado, el punto del que hablo es que para que seguir esforzandoce si ya existe en tu caja de herramientas, un destornillador, como tu dices. Y de hecho si, quiza el error esta ahi, no se obtiene el mismo resultado, con WCF por mas envolves seguira siendo feo.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s