REST vs SOAP, Perspectiva Desde REST - Mullin Stack
Better code – Better human
Better code – Better human

REST vs SOAP, Perspectiva Desde REST

Los servicios web son sistemas de software diseñados para soportar una interacción interoperable equipo a equipo. Es decir deben ser capaces de interactuar y funcionar independiente de la plataforma o tecnología.

En la actualidad los más populares y usados son SOA y REST dos arquitecturas  de software para servicios web. Los servicios SOAP vienen dados con la visión Orientada a Servicios siguiendo los conceptos de la arquitectura SOA por otro lado los servicios REST (Representation State Transfer) intentan emular los servicios HTTP o protocolos similares, son un estilo de arquitectura de software para sistemas hipermedia basado en una serie de principios los cuales definen como los recursos son definidos.

Quiero centrar este artículo en una de las pregunta que todos los desarrolladores nos hacemos a la hora de desarrollar un servicio web ¿Por qué usar REST en vez de SOAP?  Y ciertamente las respuestas varían en función del conocimiento, experiencia o simplemente fanatismo que en más de alguno debe existir.

La arquitectura REST intenta tomar todas las características tan exitosas de la web, siendo esta la única que ha podida ser escalable y extensible en el tiempo debido a sus formatos basados en URIs las cuales definen los recursos los demás son objetos conceptuales.

Existe una buena cantidad de razones por las que deberíamos usar REST en vez de SOAP y para ello nos basamos en lo que definen los principios de REST. En primer lugar por el principio de escalabilidad de la interacción con los componentes, ya explicamos anteriormente que REST emula los principios de los protocolos HTTP y todos hemos sido  testigo del crecimiento exponencial que ha tenido la web, esto sin degradar su rendimiento, aun cuando existe una diversidad de clientes conectados sistemas móviles, industriales, estaciones de trabajo, etc.

La generalidad de las interfaces es una segunda razón por la que deberíamos usar REST, debido a la simplicidad del protocolo HTTP cualquier cliente puede interactuar con cualquier servidor sin la necesidad de ninguna configuración contrario a lo que se necesita para SOAP.

Y una  tercera razón es el hecho de que REST tiene una gran compatibilidad con componentes intermedios. El uso de la cache para mejorar el rendimiento, firewalls para reforzar las políticas de seguridad entre otros componentes. La compatibilidad con estos componentes nos permiten  reducir el tiempo de espera en las interacciones y fortalecer la seguridad.

El estilo de arquitectura REST debe cumplir una serie de restricciones para que se cumplan los principios que en párrafos anteriores hicimos mención. El cumplimiento de estas restricciones son las que hacen que verdaderamente sea un estilo extensible y escalable en el tiempo.

Para REST los recursos deben ser uniformemente accesibles esto se logra mediante el uso de URIs que no son más que URLs únicas o representaciones conceptuales del recurso los cuales no pueden ser accedidos directamente sino más bien por medio de representaciones.

La comunicación cliente/servidor sin estado es otra de las virtudes de REST. Cada mensaje HTTP contiene toda la información necesaria para comprender la petición. Esto genera como resultado que ni el cliente ni servidor  necesiten recordar los estados de las comunicaciones entre los mensajes.

Por ultimo mencionare no por menos importante el hecho de que REST necesita el uso de documentos de hipermedia los cuales deberían existir tanto en el cliente como en el servidor, esto le sirve tanto para la información de la aplicación como para las transiciones de estado de la aplicación. La representación de estos estados generalmente en REST son archivos HTML o XML. Gracias a esto es posible navegar de un recurso a otro mediante el uso de enlaces sin la necesidad de registros adicionales.

 

Por otra parte el desarrollo de servicios basados en REST ofrece al desarrollador la posibilidad de usar cualquier formato para el intercambio de información. Podemos usar JSON por ser más ligero y con mayor soporte por los navegadores clientes. Pero además podemos usar el formato estándar XML usado por SOAP.

Para concluir podemos afirmar que el desarrollo de servicios basados en la arquitectura REST nos ofrece la posibilidad de escalabilidad en la interacción con los componentes, la interacción  de los clientes no requiere de configuración alguna o compleja y existe una gran compatibilidad con componentes intermedios. Es más rápido en el paso de mensajes, está más cerca de otras tecnologías gracias a su filosofía de diseño y no requiere de herramientas costosas y de compleja configuración e implementación.

Leave a comment

Your email address will not be published.