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?.

Artículos relacionados

Concurrencia VS Paralelismo A pesar de que hoy en día casi todas las aplicaciones trabajan con múltiples hilos de ejecución y que los programadores saben utilizarlos, muy poca ge...
Integración de aplicaciones con Cross Reference Cross Reference o Referencias cruzadas es una de las técnicas más utilizadas para la integración de aplicaciones basadas en Arquitectura SOA, en don...
Escalabilidad Horizontal y Vertical La escalabilidad es la capacidad del software para adaptarse a las necesidades de rendimiento a medida que el número de usuarios crece, las transaccio...

Oscar Blancarte

Ideológico, Innovador y emprendedor, Padre, Tecnólogo y Autor, amante de la ciencia y la tecnología en todos sus colores y sabores. Arquitecto de software & Full Stack Developer con experiencia en la industria del desarrollo de software y la consultoría. Amante de la programación y el Ajedrez.

28 comentarios en “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.

  3. Si se hace un análisis serio del contexto que se esta trabajando, técnicamente debería ser más fácil saber que usar, personalmente prefiero SOAP por la robustez, la seguridad y el control y validación que ofrecen los esquemas; Ejemplo de uso: integración de cores bancarios o pasarelas de pago.

    Sin embargo en algunas ocasiones es más práctico usar REST, temas front por ejemplo.

    Saludos.

    1. Es correcto lo que dices, siempre será necesario un análisis del problema a resolver, pues decir que una tecnología es mejor que otra, sin analizar el problema, sería un error.

      Sin embargo, coincido contigo, en lo particular me agrada más trabajar con SOAP, por los mismas cosas que mencionas.

      Lo interesante a analizar ahora, es como las API Rest están creciendo a un ritmo muy rápido, sobre todo por tecnologías como Angular, React y Javascript.

  4. Interesante artículo amigo Oscar. Por lo que puedo inferir, en lo referente a banca y servicios de pagos en general sería más apropiado utilizar servicios SOAP por ser más robustos, a pesar del crecimiento gigantesco que viene teniendo REST, cierto?. Por otro lado, cuál vendría siendo la diferencia entre REST y REStful??. Saludos.

    1. Hola Daniel, si bien no existe una regla clara de donde utilizar SOAP o REST, la verdad es lo que comentas es muy acertado, yo lo haría así, pues el XML me permite tener una archivo mucho mas estricto y con una nomenclatura mas clara.
      Con respecto a REST y RESTful, la diferencia es que REST es la arquitectura de software que se base en HTTP, mientras que RESTful son los servicios construidos utilizando esta arquitectura. si quieres saber mas te dejo el link a un articulo de mi amigo Cesar, donde habla precisamente de este tema: http://centripio.io/solucion-al-mal-concepto-entre-servicio-web-service-rest-y-aplicacion/

      1. Perdón, algo no me queda claro cuando dices “REST es la arquitectura de software ” , sin embargo tu artículo mencionas que la arquitectura es SOA.

        1. Hola Beto, puede llegar a ser confuso por que mezclamos muchos conceptos, sin embargo tratare de explicarme mejor.

          Tanto SOA como REST son Arquitecturas de Software, SOA promueve la construcción de servicios como un medio de interoperabilidad entre aplicativos, mientras que REST es una arquitectura que promueve la construcción de servicios basados en HTTP. En este sentido, podemos apreciar que los las dos arquitecturas hablan de servicios, sin embargo, SOA es una arquitectura de más alto nivel que incluso puede abarcar a REST.

          Espero que esto aclare tus dudas.

          1. Creo que la mejor forma de entender la diferencia entre uno y otro concepto es considerando lo siguiente :
            SOA : Es la especificación de la arquitectura orientada a servicios.
            SOAP : Es la implementación de SOA basado en XML y diversos protocolos.
            REST : Es la implementación de SOA basado en JSON y estrictamente HTTP.
            RESTful : Es el servicio propiamente dicho construido con REST.

            SOAP fue la primera implementación y por lo tanto es mas pesado y costoso de desarrollar y mantener en el tiempo, REST es la siguiente evolución de la implementación y ha sido pensada para la escalabilidad, flexibilidad y rapidez, lo cual da una mayor facilidad de desarrollo y mantenimiento de cambios a futuro ( y para dar soporte a la comunicación móvil y al internet de las cosas), también la seguridad es incluso mejor que con SOAP ya que permite fácilmente implementar o consumir cualquier API de seguridad como por ejemplo OAuth de Google (básicamente se puede crear cualquier escenario planteado con SOAP y mas).

            Saludos.

          2. Muy bueno tu resumen, un que yo diverjo en dos puntos, yo creo que las dos arquitecturas son igualmente escalables y seguras, además que en SOAP también puedes utilizar OAuth o cualquier otra autenticación por medio de tokens.
            Saludos por el comentario

          3. “aunque yo diverjo en dos puntos, yo creo que las dos arquitecturas son igualmente escalables y seguras, además que en SOAP también puedes utilizar OAuth o cualquier otra autenticación por medio de tokens”

            Por eso dije que con REST se puede resolver cualquier escenario planteado con SOAP …
            No es que SOAP sea menos seguro que REST pero tampoco es al contrario, pues el objetivo de implementar REST es precisamente mejorar la eficiencia en los servicios y darles mayor flexibilidad en áreas que SOAP seria demasiado pesado y difícil de mantener (por ejemplo en plataformas móviles e IOT).
            Obviamente si alguien tiene ya montada su arquitectura con SOAP y no requiere acceso desde apps pues es evidente que debe seguir escalando en SOAP, pero si necesita conectarse a los servicios de esa manera, tendrá que migrar su plataforma de servicios si quiere que para sus clientes sea transparente la comunicación (en este caso es mas barato exponer en REST los métodos necesarios desde SOAP). En el caso que no se tenga implementado nada entonces lo ideal es que se haga en REST ya que hay una alta probabilidad de que se termine necesitando acceso móvil y de ser así no se tendría que hacer nada a futuro.

            Saludos.

  5. Ciertamente en lo que dices no te falta razón, sin embargo, hay un problema gravísimo con SOAP, y es que por definición no se adecúa a la velocidad de evolución, por ejemplo, de las aplicaciones en una organización. Te pongo el ejemplo de una arquitectura que tenemos en mi empresa, donde tenemos clientes livianos regados geográficamente por varios países se LATAM, los cuales llaman servicios en nuestra API RESTful, pues nosotros constantemente estamos evolucionando nuestra aplicación y nuestra capa de servicios se ve afectada con cierta frecuencia, si nuestra API no fuese RESTful sino SOAP, tendríamos un escollo enorme, y es que cada vez que haces una modificación al WSDL, todos los clientes deberán regenerar los stubs para poder seguir llamando a los servicios; algo que no pasa con REST, pues siempre la versión antigua de los clientes llama a los servicios enviando lo que su funcionalidad tiene programado enviar, y el API “reconoce” esa comunicación de forma transparente, haciendo las acciones base sin exigir que el cliente tenga que enviar la nueva data de la versión más actual del API (y los clientes).. SOAP como bien dices es bueno por la robustez, sin embargo en los tiempos actuales, donde todo cambia tan rápido y donde la evolución es diaria, la robustez poco importa (dependiendo de la aplicación, claro); así los servicios que no evolucionen con tanta frecuencia pueden aprovechar la robustez de SOAP, REST también puede suplir cualquier escenario que tengas implementado con SOAP, pero lo contrario es más complejo de llevar a cabo. Un saludo..

    1. Hola Álvaro.
      Concuerdo contigo en dos cosas, primero, que REST es más Ágil y segundo que REST puede suplir cualquier escenario implementado en SOAP. En estas dos cosas concuerdo plenamente.

      Sin embargo, hay algo que me llama mucho la atención, y es que mencionas que cambias frecuentemente los contratos, pues en mi experiencia, una aplicación que tiene que mover con mucha velocidad sus contratos, es porque sus servicios no fueron planeados correctamente. Además, por lo que me dices, no acostumbras a versionar los servicios, por ejemplo (/services/v1/myservice y /services/v2/myservice) esto te permite mantener compatibilidad con aplicaciones antiguas hasta que tus clientes terminan de migrar.

      Por otra parte, no todas las tecnologías se basan en la creación de stubs para manipular los datos, tenemos tecnologías como XSLT y XPATH que nos permite transformar y recuperar la información, sin necesidad de crear objetos.

      Yo cerraría diciendo que las dos tecnologías hacen lo mismo, lo importante es cuál de las dos te da mejores resultados para tu tipo de empresa. Y estaría de más entrar en discusiones acerca de cuál es mejor.

  6. Hi, Oscar como vas.

    Excelente articulo y muy útil, en general pienso que SOAP es mucho mejor por su robustez y por la seguridad que las empresas deberán asumir día a día con mas efectividad, pero como lo dices depende del problema utilizaría uno o otro.

    1. Hola Camilo.

      Es verdad, puede sonar muy genérico decir, “según el problema a resolver” o “depende del problema” pero en el software así es, toda tecnología o arquitectura que quieres usar, por más buena que sea, si se aplica para resolver el problema equivocado, se puede convertir en la peor solución.
      Con respecto a la seguridad, propiamente dicho, yo creo que los dos son iguales de seguros, pues los dos utilizan el mismo protocolo de transporte que es http o https.

      1. Hola Oscar

        Antes que nada excelente artículo han sido de gran ayuda al igual que los comentarios y sus respectivas respuestas, pero me queda una duda, en todo lo que estuve leyendo al mencionarse que SOAP es más “robusto”, en mi mente (al parecer erróneamente) lo relacionaba con la seguridad, pero en tu comentario anterior veo que citas lo siguiente: “Con respecto a la seguridad, propiamente dicho, yo creo que los dos son iguales de seguros, pues los dos utilizan el mismo protocolo de transporte que es http o https”.

        Entonces me surge la siguiente duda: ¿Que ventaja te da el hecho que sea más robusto?

        De antemano gracias, saludos.

        1. Hola Santos,
          No estoy seguro si dije la palabra adecuada, pero cuando digo robusto, me refiero a que el que protocolo SOAP es fuertemente tipado, pues al estar basado en XML, te permite definir estructuras con Namespaces, adicional, soporta atributos, los cuales son metadatos adicionales que pueden ser agregados a cada tag. Por otra parte, cuando trabajamos con JSON, el mensaje puede ser mas abierto a la interpretación, pues no hay una regla que defina su estructura, sus posibles valores y sobre todo, el tipo de datos.

    1. Hola Carlos, es interesante escuchar buenos comentarios de vez en cuando, te lo agradezco. Por otra parte, te invito a que te suscribas para que recibas todas las actualizaciones.

      saludos.

  7. Oscar
    Buen articulo, sobre todo bastante claro en las explicaciones.
    Bueno tambien que te hayas tomado el tiempo de responder las preguntas y comentarios dejados.
    Gracias !!!!

Deja un comentario

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