Sí, se que ando de vacaciones, pero por suerte para mí, soy de los que todavía les gusta su trabajo y, aunque no estoy trabajando, sí ando "revolviendo" en cosillas que me resultarán útiles más adelante. En concreto, en varios proyectos en los que es posible que participe se usan o se van a usar Web Services. A aprender me toca, sobre todo teniendo en cuenta que es posible que en uno de ellos sea yo el que tome la decisión de qué herramientas/tecnologías usar. Y en ello ando estos días, entre playa y terrazita, leyendo y jugueteando con los Web Services.
Aunque en el proyecto se nos aconseja el uso de .NET, yo soy más partidario de Java, básicamente por tres motivos:
- Es el lenguaje que conocemos todos los desarrolladores del grupo. De usar .NET, tendríamos un tiempo de aprendizaje mayor: los Web Services y el lenguaje.
- En Java casi todo es gratis, con el consiguiente ahorro de licencias, tanto de desarrollo como de los servidores.
- .NET nos limitaría a servidores Windows, mientras que Java nos permitiría desplegar en cualquier servidor, Windows, linux, solaris, …. Sé que está el proyecto MONO, pero no veo la necesidad de meter más complejidad al asunto.
En cualquier caso, no dudo que con .NET se puedan hacer perfectamente Web Services igual que en java, posiblemente más fácilmente integrados con otras cosas de Microsoft, pero no veo ninguna ventaja clara en lo que es estrictamente el lenguaje de uno sobre otro.
El siguiente tema es si SOAP o REST. En principio, por lo que he ido leyendo, me inclino por REST. Aparentemente es más simple y parece ser que es la nueva tendencia. Posiblemente me decida por REST, pero le veo/tengo un par de pegas/dudas.
- Al ser más nuevo, me da la impresión de que está menos soportado por los servidores/herramientas actuales. Muchas de las herramientas traen como coletilla "soporte para REST". Siempre es un riesgo meterse en algo reciente.
- De la misma forma, me da la impresión de que toca codificar más. En SOAP creas tu WSDL y aunque no he buscado con detalle, me da la impresión de que hay miles de herramientas que te generan el código tanto de la parte cliente como de la parte servidor para el uso del Web Service definido por ese WSDL. En REST posiblemente haya equivalentes, pero al ser más nuevo, seguro que hay menos o están menos desarrollados. Insisto, no he mirado en serio, es sólo la impresión que me ha dado en una búsqueda superficial.
Otra gran duda es el tipo de librerías a usar para el Web Service. He visto herramientas como Restlet, (es con la que estoy jugando), pero da la impresión de ser algo muy simple para aprendizaje, no tengo muy claro si puede servir para un servidor en producción con fuertes requisitos de seguridad. También hay cosas como JAX-WS o como Jersey, pero el verlos debajo de GlassFish y sobre todo el primero, debajo de Java EE, me da la impresión de que sería matar moscas a cañonazos. Nuestro proyecto sólo tendría unos pocos Web Services y con datos no muy complejos, aunque sí bastante trasiego.
Finalmente, está el tema de elegir servidor, hay cosas como Spring Web Services, Apache Axis 2 o cosas más tradicionales como Jetty, Tomcat o servidores más "bestias" como Glassfish o JBoss. Por un lado, las ganas de aprender me tiran a Spring, pero el irme a algo conocido me tira por Tomcat. Como he comentado, Glassfish o JBoss me parecen excesivos para lo que pretendemos.
En fin, sigo investigando y haciendo pruebas, pero cualquier sugerencia de gente con experiencia por estos lares, es bienvenida.
SOAP vs REST es equivalente a comparar Fortran 66 vs Ruby 1.9.2, antes de ponerte a implementar cosas en rest, te aconsejo leer bien el tema. El desarrollar algo en rest significa 90% del tiempo pensando y diseñando y 10% implementando, las librerías es lo de menos pues la arquitectura que obtendrás va a ser simple hasta decir basta. En soap se invertirán los porcentajes y añadirás un 100% con problemas debido a incompatibilidades entre capas o problemas sin sentido.
Este [0] posiblemente sea el mejor libro de REST, si puedes conseguirlo recomiendo la lectura 100% (además es delgadito y lectura ligera y con ejemplos y casos prácticos concretos).
[0] http://oreilly.com/catalog/9780596529260
Hola! Yo actualmente estoy trabajando en la oficina con tomcat + axis 1. Funciona a las mil maravillas. Simplemente creas tus clases java como siempre lo has hecho, y a partir de ellas se genera la hoja WSDL y las entradas en el web.xml para usar el servicio. Lo único que restaría es usar un servlet de autorregistro de servicios (para no tener que levantarlos tú por línea de comandos) y a volar. Para mi es lo más cómodo para elaborar servicios sencillos y funciona muy bien. La pega es que no soporta multipart (axis 2 sí que lo hace), aunque es algo que se puede solucionar enviando un String con el archivo en base64
Ala a darle al SOA (Service oriented architecture) que como forma de organizar las funcionalidades que tu codigo ofrece a los demas creo que es el concepto clave en el que hay que meditar, previo incluso a la implementación (ejbs,servicios web soap o rest, etc) Quiero decir que puede tener implicaciones de todo tipo mas alla de lo que es el servicio web en sí dependiendo de lo que tengas previamente.
La simplicidad de REST atrae, es como un soplo de aire fresco tras la pesadez que habia adquirido los WS SOAP con todas sus especificaciones pero no creo que se adapte a todos los contextos, temas como la seguridad y la integridad de los datos no son su punto fuerte y en entornos corporativos cerrados con bastante codigo e infraestructura heredada y datos sensibles a los que hay controlar finamente el acceso tal vez no sean la eleccion correcta. Incluso fuera de este ambito no tiene porque ajustarse al escenario final que se desea.
Aleeee
Hola,
nosotros empezamos un nuevo proyecto hace unos 6 meses y al principio no sabíamos qué hacer si SOAP, REST o qué. La idea era hacer WS para independizarnos totalmente de la interfaz que iba a desarrollar otro equipo. Empecé mirando Restlet pero al final me pareció un poco «de jueguete».
El SOAP lo descartamos casi al principio porque lo veíamos como algo «del pasado». Ahora todos los «grandes» (facebook, flickr, twitter…) han optado por REST o similar.
Al final, elegimos Spring MVC y nuestra «vista» es devolver json con la información necesaria para que la interfaz pueda pintar todo.
El dar de alta un servicio nuevo es simplemente añadirlo a un .xml y engancharlo al Controller y Service que nos interese, simple y rápido.
Saludos, Iván.
Buaf! Tras mi experiencia lo que aprendí de los servicios web es que la interoperabilidad entre tecnologías y lenguajes es mentira! Como tantas promesas de java. Te recomiendo usar lo estándar de JAX-WS con anotaciones. Siempre me quedé con la duda de si REST me hubiera dado menos quebraderos de cabeza…
Bueno no creo que SOAP sea algo del pasado. Simplemente REST se ha popularizado porque algunos servicios en Internet lo utilizan pero eso no quiere decir que haya que desechar SOAP, ni mucho menos.
Recientemente tuve que integrar una plataforma con una capacidad REST en Java y el trabajo ha sido duro dado que no es posible generar automáticamente un cliente como sí pasa con SOAP a partir del WSDL. En teoría existen los WADL que son la contrapartida de WSDL para REST pero en este caso no teníamos este formato disponible ya que no es ampliamente soportado por las implementaciones de REST sobre todo en plataformas externas a Java como era el caso. Por no hablar del problema que hemos tenido al consumir el JSON generado ya que este formato tiene diversas variaciones y no todos los clientes son capaces de consumir cualquier JSON.
Entiendo que REST+Json se puede adaptar bien a aplicaciones con modelos de datos sencillos, como muchos de los servicios que están publicados en Internet, y facilita la programación rápida de interfaces de usuario ya que es sencillo con JavaScript manejar JSON.
Pero si lo que se quiere es una aplicación robusta, con un modelo de datos bien definido que pueda validarse y en el que generar automaticamente un cliente conforme a la especificación, yo optaría por XML como formato de transferencia y muy probablemente SOAP.
En Java con JAX-WS es muy sencillo generar tanto clientes como servicios web SOAP que pueden desplegarse en un contenedor de Servlets como Tomcat.
También los servicios REST pueden desplegarse en este tipo de entornos. No es necesario para nada un servidor de aplicaciones como comentabas.
Por cierto, nosotros utilizamos Jersey como cliente REST y funciona bien. Incluso es capaz de mapear el JSON a clases Java mediante JAX-B, aunque es posible que ésto no funcione del todo o tengas adaptar la configuración si el servicio que consumes no está implementado con Jersey.
Pingback: Tweets that mention Diario de Programación » Blog Archive » Los Web Services y yo -- Topsy.com
Para decidirte no necesitas sólo evaluar qué cosa es más bonita o nueva que otra, ni siquiera si es usada por los «grandes» o no, necesitas analizar cuál de ellas te va a ayudar a resolver tus problemas, todo lo demás son meras anécdotas.
Yo no tengo idea de cuál sería tu proyecto o para qué lo vas a utilizar, pero sí te puedo contar una debilidad de RESTful contra SOAP y esa debilidad créeme que definitivamente puede hacerte cambiar de opinión, claro está según la naturaleza de tu proyecto.
Sucede que RESTful es bien dado para API’s más que para servicios web como tal, RESTful funciona excelente para casos en los que el cliente no hace más que una operación a la vez, por ello en Facebook, Twitter, etc funciona. Esas grandes compañías sólo necesitas hacer una petición y listo, nada más.
Tienes que tener cuidado con la seguridad, hay que tener en cuenta que en RESTful no tienes «sesiones», es decir, no ingresas una clave y usuario y entras en una área restringida. Puedes manejar mecanismos que emulen esa seguridad mediante autenticación HTTP, mecanismos de doble llave, etc. Pero por principio en RESTful no puedes tener sesiones, no puedes guardar datos entre una petición y la otra. Por lo que si en tu proyecto se trata de usar conexiones entre sistemas privados y que necesiten manejar sesiones, RESTful no te sirve.
Otro tema son las peticiones en cascada de servicios web, y si estas peticiones tienen que lidiar con servicios SOAP que no puedas cambiar (como la de un proveedor por ejemplo), incluir RESTful a ese ambiente es añadirle más problemas que soluciones por la heterogénea forma de intercomunicación de los sistemas.
Como conclusión te puedo decir: «Las herramientas no son buenas por sí mismas, no hay herramienta mágica que lo resuelva todo, ellas son simples herramientas. Depende de cada quien elegir las mejores para terminar bien su trabajo»
@Grover Gracias por los consejos, los tendré en cuenta. De todas formas, no tengo ni idea de Web Services ni de herramientas para ellos, por eso lo de tantear un poco con todo empezando por aquello que parece tener más aceptación.
Se bueno.
Hola, te sigo desde hace tiempo, muy interesante tu blog. Mi opinión es la siguiente. La gente trata de comparar REST y SOAP, pero creo que son cosas dificilmente comparables. REST es más una forma de hacer las cosas, hay una JSR, pero no hay estándar, hay unos cuantos frameworks y librerías (entre los que incluyo el mío), que te permiten gestionar las URLs tipo REST de forma cómoda.
SOAP es otro mundo, que también tiene sus ventajas. Ya existe un estándar, y unas implementaciones que te dan bastante hecho, pero no por ello te van a hacer trabajar menos.
La pega más grande que le ponen a REST es la seguridad, que no tiene nada definido, y claro todo depende de lo que necesites, o de la seguridad que ya tengas en tu entorno. Desde luego para comunicaciones entre aplicaciones internas… la autenticación e integridad de las comunicaciones es algo secundario, con REST lo tienes que implementar tú, y con SOAP ya tienes algo hecho. Yo por ejemplo no la necesito, por eso me voy más por REST, porque es más ‘light’ en cuanto a código, y por tanto más mantenible. SOAP es un mundo, y para ciertas cosas es matar moscas a cañonazos. Para otras no, así que es cuestión de las necesidades del sistema que vayas a desarrollar que vayas a por una cosa o a por otra.
Hola, creo que la principal razón para elegir rest o soap, es quien va a utilizar el servicio. Si vais a publicar el servicio para que clientes puedan acceder a el libremente (con la restricciones de serseguridad que sean), es mas sencillo y normal usar soap ya que todo el servicio va definido en un fichero wsdl y el la unica información que necesita un cliente para utilizar tu servicio.
Si van a ser servicios web de uso «interno» es decir que el mismo equipo de desarrollo crea los servicios y los clientes puedes utilizar rest (con la salvedad de la seguridad y demas complejidades que aporta soap) ya que rest no tiene una forma de generar un «contrato» como puede ser un wsdl. En caso de rest, tendrías que generar documentación y demas para que un cliente sepa como debe ir formada una petición, como las respuestas, etc… Eso o crear un api que sea la que se encargue de todo eso y los cliente utilicen ese api para la comunicación con los servicios web.
Saludos.
REST y SOA no se pueden comparar en cuanto a características, todo depende del problema en cuestión, ya que SOA es mucho mejor para algunos tipos de servicios. SOA incentiva la reusabilidad, la independencia de la tecnología de implementación, y mucho más.
Por otra parte REST es aún mas flexible y apropiado cuando surgen problemas o hay que hacer algun cambio(todos los recursos presentan la misma interfaz a los clientes).
Si expusieran el problema en cuestión, pudiéramos establecer mejor que conviene más en ese caso. Ya q por ejemplo, se recomienda usar REST si tenemos que ofrecer servicios de la sindicación por RSS o ATOM. Pero pasa también que REST no cuenta por ejemplo con una amplia gama de estándares… y podemos seguir buscando ventajas y desventajas hasta mañana. Por eso no pienso q sea tan sencillo compararlos así de frende, sino aplicado a un problema en específico.
Saludos
[…] This post was mentioned on Twitter by Joaquin Bravo, chuidiang. chuidiang said: Los Web Services y yo http://blog.chuidiang.com/2010/08/20/los-web-services-y-yo/ […]