« Boletín del 19-03-2009Boletín del 11-03-2009 »

Web Services vs REST

16.03.2009 | por | Categorías: Software

Una de las dudas típicas a la hora de integrar dos subsistemas heterogéneos es si usar web services o REST. Evidentemente, si los dos subsistemas estuvieran desarrollados con el mismo lenguaje de programación, la integración obvia sería aprovechar lo que nos facilitase ese lenguaje, como puede ser RMI o .NET Remoting por citar sólo dos ejemplos.

Pero a lo que iba. Resulta que tenemos que integrar dos módulos que están desarrollados en dos entornos diferentes; o a lo mejor el requisito es que se comuniquen por internet, aunque compartan lenguaje de programación. En estos casos, hay que estudiar si es mejor realizar esta integración mediante web services o con llamadas REST. Vamos a ver las ventajas y desventajas de hacerlo de una manera o de otra.

Los web services tienen como principal ventaja que cualquier entorno de desarrollo (Eclipse, Netbeans, Visual Studio, etc), dispone de herramientas para generar un cliente a partir de un WSDL o exponer los métodos de una clase como servicios web. No obstante, es muy recomendable hacer una prueba de concepto antes de decidirse porque si el cliente y el servidor de servicios web no están basados en las mismas librerías, podemos tener problemas de compatibilidad.

Como ejemplo, si tenemos un cliente .NET en una PDA y un servicio web en J2EE (que use las librerías Axis, por ejemplo), es posible que si tenemos un dato de tipo timestamp, el valor sea diferente en la parte Java y en la parte .NET. Esto es debido a que en Java se usa el formato UNIX (segundos transcurridos desde la medianoche UTC del 1 de Enero del año 1970), mientras que en .NET esta cifra son el número de intervalos de 100 nanosegundos transcurridos desde las 12:00 AM del 1 de Enero del año 1. Otros problemas de compatibilidad pueden ser que el valor por defecto de las variables no inicializadas sea null en un lado y otros en la otra parte (0 para valores numéricos, "" para strings, etc).

Pero quizá lo más fácil de detectar sea la compatibilidad a la hora de encapsular ficheros dentro de un web service: ya que hay varios mecanismos (SwA - SOAP with Attachments, DIME o MTOM), es posible que si las librerías son distintas en cliente y servidor, no exista una manera compatible de transferir un fichero, teniendo que recurrir a soluciones de contingencia como montar un servicio intermedio (desarrollado con el mismo lenguaje de programación y librerías que el servidor de servicios web) que reciba el fichero como parte de un form-multipart y que luego lo encapsule de forma compatible para el destinatario final (el servicio web).

Por otro lado, los web services nos proporcionan otras ventajas como el tipado fuerte (en el WSDL está definido de qué tipo son las variables, incluso en el caso de objetos complejos) o los estándares WS-*: WS-I BasicProfile, WS-Security, WS-Addressing, WS-RM o WS-Policy. Eso sí, si los vais a utilizar, es mejor asegurarse de la compatibilidad entre librerías si son distintas en cliente y servidor.

En el caso de utilizar REST, perdemos lo del tipado fuerte y los mecanismos estándares WS-* mencionados anteriormente, pero ganamos universalidad: muchos dispositivos programables son capaces de hacer peticiones HTTP. Eso significa que podemos integrar una aplicación desarrollada en J2ME con nuestro servidor sin necesidad de que soporte la JSR para web services, por ejemplo.

Hasta hace poco, no había manera de generar clientes de manera automática para hacer invocaciones REST. Afortunadamente, descubrí que existía la librería Jersey del proyecto GlassFish, que permite desarrollar tanto servicios de servidor basados en REST (simplemente con etiquetas en los lugares oportunos) como clientes que los consuman de manera automática. Esto es debido a que los servicios generados con esta librería despliegan un descriptor WADL muy similar al WSDL de los web services tradicionales, por lo que luego se puede partir de ahí para generar los clientes correspondientes.

Para subir o bajar ficheros si optamos por esta modadalidad, basta con utilizar comunicaciones HTTP estándar como POST (con un form-multipart, por ejemplo) o GET (una simple petición a la URL de un fichero); ambos mecanismos son sencillos de implementar y hay muchos ejemplos en internet en casi cualquier lenguaje de programación.

Así que, como veis, elegir uno u otro método de integración requiere una breve pausa para reflexionar y hacer las pruebas oportunas para asegurarnos de que no va a haber problemas de incompatibilidad que nos puedan dar sorpresas en medio del desarrollo. Dedicarle unas jornadas a estas pruebas puede ahorrarnos semanas enteras de problemas cuando el proyecto ya esté lanzado.

 

No hay opiniones, todavía


El formulario está cargando...

Buscar

Linkedin

Ver perfil de Alberto de Vega Luna en LinkedIn

Licencia

Creative Commons License
Esta obra se publica bajo una licencia de Creative Commons. Es necesario citar la fuente y el autor si se utilizan estos contenidos.
powered by b2evolution free blog software