REST vs SOAP al servicio de la web

REST vs SOAP al servicio de la web

Las últimas semanas estuvimos involucrados en un proyecto interesante que me hizo vivir de cerca la materialización de la evolución de la WEB. Es imposible hablar de la WEB moderna sin mencionar  a los Web Services,  y no entrar en el debate REST vs SOAP.

REST (Representational State Transfer) es una arquitectura sencilla que se ejecuta sobre HTTP.  En su disertación, Roy Fielding describe a REST como un “estilo de arquitectura” que explora de una forma básica la tecnología existente y los protocolos de la Web, incluyendo XML y HTTP.

Por su vez, SOAP, Simple Object Access Protocol es una especificación de protocolo para intercambiar información estructurada en la implementación de Web Services.

En este pequeño post haré una breve comparación entre los dos enfoques y animar a la reflexión.

Siendo REST  un estilo de arquitectura que describe el acto de transferir un estado por sus representaciones,  el siguiente ejemplo permite ilustrar el proceso:

Juan tiene tienda de ropa y entre otras cosas, en la tienda tiene 5  pantalones, 13  camisas y 4 camisetas. Supongamos que yo soy su cliente y Juan está utilizando la API de REST. Si quiero saber el estado actual de su tienda, lo único que tengo que hacer es pedir: ¿“Estado”?

Juan me contestaría: “5 pantalones, 13 camisas, 4 camisetas”. Sencillo, ¿no? Juan  acaba de transferirme el estado de su tienda por medio de una representación: “5 pantalones, 13 camisas, 4 camisetas”.

Si quisiera utilizar la forma REST para decirle a Juan que añade 3 camisetas a su tienda no podría simplemente decirle: “Juan, por favor añade 3 camisetas a tu tienda”, Juan me contestaría algo como: “400, Bad Request. ¿Qué quieres decir?”

Pues intentamos nuevamente. Como haríamos con la forma REST? ¿Cuál era la representación? Era “: “5 pantalones, 13 camisas, camisetas”. Intentamos transferir la representación…

Yo: “Juan, … 5 pantalones, 13 camisas, 6 camisetas  … por favor!”

Juan: “De acuerdo!”

Yo: “Juan, … ¿cual es tu estado?”.

Juan: “5 pantalones, 13 camisas, 6 camisetas”.

Yo: “Ahh, de acuerdo!”

Por el ejemplo podemos ver que el REST  simplifica la comunicación y no le parece necesario discutir temas como “añadir una camisetas de que marca”, “o remover todos los pantalones”, “o duplicar la cantidad de camisas”? Todo lo que tenemos que discutir es la representación, y utilizar esta representación para conseguir lo que queremos.

¿Porqué escoger REST o escoger SOAP?

REST utiliza HTTP, entonces es mucho más sencillo. Desarrollar APIs, crear clientes y la documentación es más fácil de entender.

REST permite inúmeros formatos de datos, dando por ejemplo al desarrollador la posibilidad de utilizar JSON que normalmente es más rápido y como permite la utilización de JSON, permite también un mejor soporte a los clientes del explorador. SOAP solamente permite XML,

REST tiene mejor escalabilidad y rendimiento.

Las lecturas del REST se pueden cachear, las lecturas basadas en SOAP no se pueden.

SOAP es interesante a la hora de hablar de seguridad, pues si REST soporta SSL, SOAP también lo hace, pero también soporta WS-Security lo que añade características de seguridad Enterprise.

SOAP Proporciona una implementación estándar de integridad de datos i privacidad de datos.

REST no tiene un sistema de mensajería estándar y no puede lidiar con la comunicación de fallos. SOAP proporciona fiabilidad en este sentido, incluso a través de intermediaros SOAP.

Obviamente la decisión, como siempre depende del tipo de aplicación que se quiere desarrollar y de la inversión que se pueda hacer sobre la misma.

Si lo importante es desarrollar algo sencillo y práctico, REST puede ser la solución. Pero si la seguridad es prioritaria, SOAP puede ser útil e importante.

Fuentes: javacodegeeks.com, spf13.com y ics.uci.edu

]]>

9 Comments


Dani
03/02/2014 at 18:20
Reply

Para mi lo importante es analizar qué datos vamos a enviar en cuanto a volumen y estructura, así como qué tipo de control necesitamos y luego, una vez entendidas las diferencias entre REST y SOAP, y si el sistema nos lo permite, escoger la arquitectura adecuada.
Gracias Chiyana!


Antonio
27/11/2014 at 03:52
Reply

Buen artículo y sencilla explicación. Me ha gustado especialmente el ejemplo sencillo que has plasmado.


Alfonso
06/03/2015 at 00:17
Reply

Gran artículo. Gracias a él todo me ha quedado mucho más claro.
El ejemplo es genial.


Luis Flores
21/04/2015 at 00:17
Reply

Buen dato muchas gracias….


JV
07/05/2015 at 20:01
Reply

Muy buen artículo. me ha brindado más claridad al respecto.
Gracias!


Jesus Perales
13/07/2015 at 23:17
Reply

Muy bueno !!


Jordi fcb
28/08/2015 at 08:43
Reply

Muy practica y sencilla explicación Chiyana. Gracias por compartir conocimientos.


Nito
11/03/2016 at 00:54
Reply

Me pareció un artículo muy claro y es una gran duda que hoy aparece en las áreas de sistemas de las grandes empresas a la hora e elegir un protocolo. Una duda? Entiendo que no se aconseja utilizar servicios soap para dialogos desde una mobile. Me porían enriquecer este tema??
Gracias


Leave A Reply

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

Déjate sorprender...

Gestionar el consentimiento de las cookies

Para ofrecerte la mejor experiencia de uso, utilizamos tecnologías como las cookies para almacenar y/o acceder a la información del dispositivo. El consentimiento a estas tecnologías nos permitirá procesar datos como el comportamiento de navegación o las identificaciones únicas en este sitio. No consentir o retirar el consentimiento, puede afectar negativamente a ciertas características y funciones.

Funcional

Siempre activo
El almacenamiento o acceso técnico es estrictamente necesario para el propósito legítimo de permitir el uso de un servicio específico explícitamente solicitado por el abonado o usuario, o con el único propósito de llevar a cabo la transmisión de una comunicación a través de una red de comunicaciones electrónicas.

Estadísticas

El almacenamiento o acceso técnico que es utilizado exclusivamente con fines estadísticos. El almacenamiento o acceso técnico que es utilizado exclusivamente con fines estadísticos anónimos. Sin una requerimiento, el cumplimiento voluntario por parte de su proveedor de servicios de Internet, o los registros adicionales de un tercero, la información almacenada o recuperada sólo para este propósito no se puede utilizar para identificarlo.

Marketing

El almacenamiento o acceso técnico es necesario para crear perfiles de usuario para enviar publicidad, o para rastrear al usuario en un sitio web o en varios sitios web con fines de marketing similares.