SOAP vs REST ¿cual es mejor?

SOAP vs RESTSOAP vs REST es una comparación que muchos programadores o incluso arquitectos de software suelen preguntarse a la hora de desarrollar las API para sus sistemas, pero cual es realmente la diferencia que existe entre ellas, ¿Será que una es superior a la otra? ¿Será que REST llego para remplazar a SOAP? Pues bien, en este artículo trataremos de resolver esta gran duda.

 

Primero que nada, me gustaría aclarar un error muy común que puede hacer que distorsione por completo tu entendimiento con respecto a los Web Services y es que SOA no es igual que SOAP y tener Web Services no significa que tenemos SOA. Hace un tiempo publique un artículo donde hablaba acerca de la Arquitectura SOA por si quieres darle una repasada al tema.
Pues bien, ya con este punto aclaro, debemos entender que SOA (Service-Oriented Architecture) es un tipo de Arquitectura de Software y no una tecnología o producto. SOA es una arquitectura que se base en la integración de aplicaciones mediante Servicios, los servicios representan la medida más granular de la arquitectura, sobre la que se construyen otros artefactos como: composiciones, proxys, fachadas, BPM e incluso API completas. Ahora bien, si SOA tiene como médula espinal los servicios, ¿no son SOAP y REST servicios? ¡Revelador no!!
Entonces si REST y SOAP son en realidad servicios, entonces que diferencia existe entre las dos, cual es el propósito de que existan dos tecnologías que aparentemente hacen lo mismo. Primero entendamos que SOAP y REST siguen la misma Arquitectura (SOA), por lo que las dos deberían de apegarse a los mismos principios.

 

SOAP vs REST

En este punto nos debe de quedar claro que tanto SOAP como REST son tecnologías que implementan la arquitectura SOA.

Que es SOAP:

Los servicios SOAP o mejor conocimos simplemente como Web Services, son servicios que basan su comunicación bajo el protocolo SOAP (Simple Object Access Protocol) el cual este definido por Wikipedia como “protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML”. Por lo tanto, queda claro que la comunicación se realiza mediante XML, lo cual nos debe de quedar muy claro, pues es en este aspecto donde radican las principales diferencias contra REST. Los servicios SOAP funcionan por lo general por el protocolo HTTP que es lo más común cuando invocamos un Web Services, sin embargo, SOAP no está limitado a este protocolo, si no que puede ser enviado por FTP, POP3, TCP, Colas de mensajería (JMS, MQ, etc). Pero como comentaba, HTTP es el protocolo principal.

SOAP vs REST

 

Si bien, me gustaría poner una sección de ventajas y desventajas, la realidad es que estas pueden ser lo contrario dependiendo del punto de vista y la situación concreta del problema a resolver por lo que me gustaría dejar un breve análisis de cuando utilizar SOAP. A mi parecer SOAP sigue siendo el mejor protocolo para la comunicación de Server to Server o Partner to Partner pues es un protocolo mucho más robusto, tiene un tipiado mucho más fuerte, permite agregar metadatos mediante los atributos (cosa que JSON no tiene), permite definir espacios de nombre, evitando la ambigüedad. Por lo mismo, SOAP es un formato más pesado, tanto en tamaño como en procesamiento, pues los XML tiene que ser parseado a un árbol DOM, resolver espacios de nombre (namespaces) antes de poder empezar a procesar el documento. Los XML además tienen métodos de validación muy potentes y ampliamente utilizados, a diferencia de JSON, el cual, si tiene forma de validar, pero no son tan potente y su utilización es pobremente utilizada (no significa que en el futuro no se estandarice su uso).

Nótese que, SOAP solo soporta formato XML, por lo que cuando lo que necesitamos es flexibilidad y un performance superior, podemos optar por REST. Tengo otro artículo donde hablo de XML vs JSON por si quieres profundizar en el tema.

Que es REST

Por otra parte, tenemos REST, el chico nuevo de la cuadra. REST ya tiene unos años, pero en realidad tiene poco que se le empezó a dar la importancia que hoy tiene. REST es una tecnología mucho más flexible que transporta datos por medio del protocolo HTTP, pero este permite utilizar los diversos métodos que proporciona HTTP para comunicarse, como lo son GET, POST, PUT, DELETE, PATCH y a la vez, utiliza los códigos de respuesta nativos de HTTP (404,200,204,409). REST es tan flexible que permite transmitir prácticamente cualquier tipo de datos, ya que el tipo de datos está definido por el Header Content-Type, lo que nos permite mandar, XML, JSON, Binarios (imágenes, documentos), Text, etc. que contrasta con SOAP que solo permite la transmisión de datos en formato XML. A pesar de la gran variedad de tipos de datos que podemos mandar con REST, la gran mayoría transmite en JSON por un motivo muy importante, JSON es interpretado de forma natural por JavaScript, lo que ha hecho que frameworks como Angular y React se aprovechen al máximo, pues pueden enviar peticiones directas al servidor por medio de AJAX y obtener los datos de una forma nativa. Los formularios de HTML pueden ser apuntados a los servicios REST sin ningún problema (por ejemplo).

SOAP vs REST

 

Otra de las grandes ventajas que presenta JSON sobre SOAP es el performance, ya que los JSON son considerablemente más livianos en peso y mucho más rápido en su procesamiento. Pero como ya vimos, el performance tiene un costo, y es la robustez del mensaje como tal.

Ahora bien, desde mi punto de vista REST debería ser utilizado para obtener datos en aplicaciones WEB que funcionan principalmente con el Modelo MVC del lado del cliente, es decir, que todos los procesamientos se realizan desde el navegador y que solo va al backend para obtener o actualiza la base de datos. Otra de las situaciones es cuando tenemos aplicaciones donde los recursos de procesamiento son bajos y con ancho de banda limitado, como sería el caso de las aplicaciones móviles o robótica.

SOAP vs REST Conclusiones

Como vimos en este análisis, no hay un claro ganador, pues tanto SOAP como REST siguen siendo muy útiles en condiciones diferentes, incluso existen aplicaciones que ya exponente todas sus API’s en SOAP y REST para asegurar que la integración con ellas sea lo más natural posible sin importar la aplicación con la que se estén integrado.

Cabe mencionar que REST ha estado tomando fuerza a una velocidad impresionante y más con la llegada de NodeJS y las bases de datos NoSQL como MongoDB. Sin embargo, el hecho de que REST tome fuerza, no significa que le esté quitando protagonismo a SOAP, pues recordemos que con la llegada del Internet de las cosas (IOT) cada vez se conectan más dispositivos a internet que necesitan ser integrados (una gran oportunidad para REST) y es donde REST está tomando la delantera.

La verdad es que el futuro no se ve claro, pero lo que, si es que a pesar de que REST siga tomando fuerza, SOAP sigue siendo una tecnología muy robusta y extremadamente utilizada por lo que una cosa si es segura, a SOAP todavía le queda un largo camino.

A pesar de todo este análisis, lo importante es tu qué opinas, ¿cuál crees que sea el futuro?, ¿crees que REST poco a poco matara a SOAP? O ¿simplemente SOAP seguirá funcionando a la par con REST?.

8 thoughts on “SOAP vs REST ¿cual es mejor?

  1. Muchas gracias por esta publicacion, estaba en ceros con esto de los Servicios Web y ya estoy adentrándome un poco, ahora una duda y consejo espero alguien pueda ayudarme.

    Cual de estas 2 arquitecturas (SOAP o Rest) seria mejor implementas para realizar una concentración de información tomando en cuenta que son 100 clientes (Aumentando constantemente) los que enviarían la información, estoy un poco confuso debido a que no tengo experiencia en este ramo.

    Les comparto mi idea, es reemplazar el Broker de SQL que tenemos en mi empresa, por los Servicios Web, y de esta manera poder también tener una mejor comunicación y mas rápida. tomando en cuenta que no se requiere pagar de una licencia SQL (SQL Expres no cuenta con esta herramienta el “Service Broquer”, hasta donde tengo entendido) .

    Si me puede alguien ayudar a aclarar mi idea, pues muchas gracias de antemano

    1. Hola Joel, en realidad el número de registros yo no lo tomaría como la clave para determinar que tecnología utilizar, ya que tanto REST como SOAP son protocolos bastante capases de atender grandes volúmenes de información, yo creo que tienes que analizar que es más conveniente para tí, tanto en tiempo de desarrollo, tecnologías y sobre que dispositivos o tipos de APP los vas a consumir. Lo que si te puedo decir por lo que me comentas es que el broker lo utilizas únicamente para exponer los datos, pero no para crear servicios de negocio. La arquitectura SOA permite que tu más que exponer solo datos, expongas operaciones de negocio con el cual puedas interactuar con BackEnd.

      1. Gracias Osca, bueno pues por el momento solo pretendo centralizar la información en un servidor y a viceversa enviar información de mi servidor hacia los clientes, pero posteriormente quiero trabajar con dispositivos portátiles, que sean capases de realizar las peticiones al servidor y que no sea costoso en tiempo y recursos tanto del dispositivo como del servidor (Estuve leyendo un poco y al parecer para esto lo mejor seria REST aunque no se si SOAP sea factible igual para dispositivos móviles), así como también el envío de archivos o actualizaciones a mi sistema.

        1. Hola Joel, no conozco a detalle las necesidades de tu desarrollo, pero lo que si es un echo, es que las dos tecnologías te sirve a la perfección. Pero yo te sugeriría que tomarás la tecnología que más se te facilite en la implementación, yo en lo particular, cuando desarrollo API´s para terceros, suelo utilizar SOAP, debido a que tiene un Tipeado mucho mas fuerte y puedes exponer un Contrato (WSDL) de forma más simple. sin embargo esto no es regla, es solo un Overview sobre lo que alcanzo a entender de tu desarrollo.

          1. Bueno en este caso es un desarrollo interno y cuando hablo de dispositivos móviles me refiero a dispositivos propios de la empresa (Gerencias, supervisores, etc…) de igual manera agradezco tus comentarios. Comenzare con SOAP.

            Como sea te comento un poco el desarrollo, es una cadena pequeña de tiendas y lo que requiero es centralizar la información de ventas compras, traspaso, pedidos de central el envió de productos, precios, promociones, Etc..
            Como te comentaba actualmente estoy enviando la información de cada punto con el Service Broker de SQL.

            Las gerencias requieren de consultar las ventas por ejemplo en tiempo real cosa que podría solucionar con enviar la información a la nube, pero la idea es Economizar, entonces por eso opte por los Servicios Web.

            Estamos con este cambio, porque no queremos quedar estancados con la tecnología, se que el Broquer es nativo de SQL y se seguirá utilizando, pero para nosotros ya no es factible aunque en su momento lo fue, me he dado cuenta que en los PDV que he investigado utilizan servicios Web para la comunicación de su información.

            Agradezco el tiempo que has tomado para realizar tus comentarios y por esta publicación muí buena.

  2. Que tal muy buenas tardes, me han llegado a comentar por parte de un Aruquitecto de Software que para invocar servicios para dispositivos moviles es mas conveniente usar REST por la flexibilidad de los mensajes, tal vez esto sea cierto, pero en estos momentos se me solicito un desarrollo en SOAP para una aplicacion movil, representara una desventaja en el rendimiento de la aplicacion ? ya lo tengo casi terminado pero es conveniente tambien hacer su equivalente en REST ?

    Saludos!

    1. Hola Luis, los servicios REST son por lo general, una mejor opción para el desarrollo movil, eso si es verdad. Por otra parte, si te solicitaron desarrollar un servicio SOAP pues que más te queda… podrías argumentar que es mejor usar REST para ver si cambian de opinión, pero si no, entonces pues quedate con el SOAP. Ahora bien yo no vería sentido desarrollar dos servicios iguales (SOAP y REST), en tal caso es analizar con tu líder por cual inclinarse.

Deja un comentario

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