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