SOAP vs REST ¿cual es mejor?

SOAP vs REST

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

Te invito a mi curso de Mastering API REST con Spring Boot

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.

Te invito a que vas mi articulo “Construir un API REST con NodeJS“, en el cual hablo desde cero como implementar un API REST de la forma más simple y clara, utilizando NodeJS y Express. O puedes puedes ver la guia completa de cómo implementar un API REST con Java desde cero.

Te puede interesar mi video de Youtube”Qué es API REST? – 🚀Y por que es importante aprenderlo 🚀

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

123 thoughts to “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.

          1. Hola Arturo, en lo personal no he trabajado con esas dos librerías que mencionas, pero me imagino que han de ser buenas, claro dependerá de lo que necesites

          1. En realidad es prácticamente lo mismo, lo que si, es que yo te recomiendo que te utilices REST, SOAP ya va de salida.

            saludos

    2. Hola Joel, primero que nada. tomar en cuenta la diferencia.
      arquitecturas son como Mainframe, Cliente servidor, SOA. Pero SOAP y REST son servicios, tecnología o productos.
      Yo creo que debas seguir usando el servicio SOAP ya que tus clientes van aumentando de poco en poco que no es sí la variable a tomar en cuenta. sino a qué tipo de aplicaciones aunque ya lo pueden desarrollar y que sean híbridas., quizá de aquí a 1 año ya lo puedes usar Rest. En mi caso, nosotros manejamos una gran cantidad de información de nuestros clientes y para diferentes equipos móviles, nuestros centros comerciales necesitan información rápida, por tanto mi jefe me pidió que lo desarrollemos en REST(Json).
      Saludos,

  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.

      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 !!!!

      1. OSCAR, gracias por acercarme a los conceptos, los necesitaba! Me gusto mucho la manera tan elegante como manejaste las diferencias de opinión y criterio técnico. Me recordaste algo que leí sobre como de que de un diálogo surge la verdad. En este caso, de las diferencias de opinión surge un concepto mas robusto y mas equilibrado. Los de TI escogimos una profesión muy hermosa… y que nos obliga a evolucionar siempre. Gracias por compartir tu conocimiento y experiencia. Podrías compartirme un comentario o enlace referente a ese proceso de revisión de tablas paramétricas, homologacion y estandarización que deberían hacer la organizaciones grandes que han construido muchos sistemas de informacion islas cuando deben evolucionar a SOA, la especificación de arquitectura orientada a servicios. ? Gracias nuevamente. I.HOU

        1. Hola Osio, gracias por tus comentarios los agradezco enormemente y pues claro que del dialogo nace la verdad, por que nadie tiene la verdad definitiva. A lo largo de toda mi carrera me ha tocado tragarme mis palabras al discutir con algunos colegas, pero al final de eso se trata, de aprender de los demas y ser lo suficientemente humilde para reconocer que estas en un error y aprender de ello.

          Con respecto a tu duda “proceso de revisión de tablas paramétricas, homologacion y estandarización ….” ciertamente no comprendí lo que estas buscando, podrías ser un poco más claro para ver como puedo ayudarte 🙂

          saludos.

          1. Un modelo E-R de un sistema de informacion robusto, por ejemplo de una ERP puede tener unas 2000 tablas (!)… algunas de ellas, 100, 200 que se yo son tablas parametricas, pocos registros, con pocas columnas y con pocos cambios a lo largo del tiempo. Por ejemplo: tipos de movimiento, ciudades, profesiones, etc. Las organizaciones grandes pueden tener no un sistema de informacion sino 5, 10… 50… la que yo tengo en mente tiene unos 150 sistemas de información islas y al menos una decena de ellas con modelos de base de datos que incluyen, cada sistema, 1000, 2000, 5000 tablas y millones de registros. Y las tablas parametricas, con registros comunes entre todos los sistemas de informacion, que podrian ser “compartidas” o punto de encuentro e intercambio, no lo son pues no comparten estandares de codificacion ni usan las mismas estructuras…. Imaginemos ahora diseñar un servicio en que se publiquen profesiones…. usada por varias aplicaciones….pero sin estandar. Ese problema de parametricas y su relacion en como comenzar a orientar a servicios una organizacion grande es el que quiero pensar un poco mas.

          2. Creo que te estoy entiendo, y corrígeme si me equivoco. Lo que tu dices, es que en todas estas aplicaciones existen tablas con digamos “catálogos” con información repetidas en todos los sistemas, entonces lo que tu buscas es “separar” como un servicio externo toda esta información, de tal forma que en lugar de que cada sistema guarde información repetida, mejor la busque en un servicio en común con todas las aplicaciones.

            Dada esta premisa y suponiendo que eso es lo que buscas, mi recomendación es simplemente “NO TE METAS EN PROBLEMAS” por lo general estos sistemas están muy fuertemente amarrados a sus estructuras y quitar una tabla provocaría que los query que ya tiene o Store procedures no logren hacer las Uniones (joins) con estas tablas y todo truene. Por más simple que parezca, requeriría un análisis muy profundo para determinar lo que implicaría quitar estas tablas.
            En mi experiencia, cuando se usan catálogos repetidos pero con diferentes estructuras e incluso ID’s, se utiliza algo llamado XREF o Referencias cruzadas (Cross References) lo cual consiste en tener tablas intermedias que puedan mapear el ID de un sistema origen a uno destino. Esto es muy utilizado en Integraciones SOA, sin embargo, no se cual sea el objetivo que persigues al retirar estas tablas. Te dejo este enlace en el cual hablo precisamente de cross referencia, para ver si esto es lo que estás buscando: https://www.oscarblancarteblog.com/2015/11/04/integracion-de-aplicaciones-con-cross-reference/

  8. OK, estoy de acuerdo con tu prudencia recordando lo de “si algo funciona, dejalo asi”. Pero mi intencion real no seria retirar dichos catalogos, lo cual seria horrible ciertamente, sino mirar al futuro: diseñar mejor.. Si vamos a construir un nuevo ERP, o un nuevo sistema de informacion misional por las falencias del actual….. la pregunta tiene a establecer que criterios aplicar para que estos nuevos sistemas de informacion robustos, desde su nacimiento, tengan un mejor diseño, uno mas flexible, mas integrado y tender hacia un modelo en el que catalogos estandarizados (tablas parametricas) sean parte de la solucion y no del problema. Muchas gracias por las cross reference, de hecho ya la habia leido, voy a re-leerlos, pero mi oportunidad actual de mejorar busca algo diferente. Asi, si tuviera que mandar a construir un nuevo sistema , por ejemplo un ERP u otro sistema robusto ¿ como hacer para que sea lo mas integrado posible con todos los otros sistemas y sea menos isla que los construidos a la fecha para la Organizacion?

    1. Hola Osio, no se trata de “si algo funciona, déjalo así”, mas bien se trata de analizar el beneficio real de hacer ese cambio. En mi experiencia, por querer hacer las cosas “bien” terminamos envueltos en un problema que no sabemos luego como salir. En tu lugar, yo analizaría dos cosas, el beneficio real de hacer eso y el esfuerzo en tiempo/costo que implica, si tras analizar eso, vez que efectivamente te trae beneficios, entonces adelante.

      Con respecto a tu pregunta en concreto, la verdad es que no sabría como responderte, pues yo no tengo claro cual es el problema real a resolver, en este sentido, no me queda mas que darte una respuesta genérica ante una pregunta genérica. En tal caso, se me ocurren dos opciones, crear un módulo de datos maestros, en el cual tengas toda esa información repetida entre los sistemas y luego que los demás sistemas obtenga y actualicen la información de este módulo central. La segunda opción es mediante procesos ETL, los cuales podrían sincronizar la información de forma periódica (digamos por la noche), de tal forma que todos los sistemas tenga la misma información y con la misma estructura, de esta forma, seguirás teniendo información duplicada en cada sistema, pero al menos tendrían la misma estructura y ID, lo que facilitaría la integración con el resto de aplicaciones.

      Desde luego que estas respuestas son genéricas, pues como repito, no conozco el objetivo del cambio a si como la situación actual de la empresa que mencionas. Lo que yo te puedo decir es que es normal que los sistemas tengan información duplicada, como es el caso de los catálogos, eso lo explico en el articulo de XREF.

      Espero que esta respuesta te sea de utilidad, pues si más información en mis manos, poco puedo ayudar.

      saludos.

  9. OSCAR, cada respuesta tuya dio luces muy precisas y caminos de solución para abordar un problema complejo. En forma genérica diría 2 objetivos: Uno de no cambio que lo resumiría así: si un sistema funciona, no lo toques, hasta que tengas la certeza de tener algo mejor…y probado! Y el del cambio: si voy a cambiar por obsoleto un sistema importante de un organización grande y compleja , ese sistema debe integrarse a un modelo de negocio mejor… uno que refleje más la Organización de hoy… o la de mañana…de forma que cuando otro sistema más se haga obsoleto y deba ser cambiado u otro nuevo nazca, se implanten con mayor facilidad y flexibilidad, a menor costo y en menos tiempo, integrándose al servicio de los objetivos actuales del negocio . De nuevo, gracias, por tu valiosa ayuda.

    1. Solo una cosa más que debes de tomar en cuenta, en una arquitectura SOA, el problemas de las tablas no debería de existir, pues para eso son precisamente lo Webservices, para encapsular la lógica del sistema y exponer una interface limpia y fácil de utilizar, si el día de mañana, uno de estos sistemas desaparece y es remplazado por otro, simplemente utilizamos la implementación del nuevo sistema y listo.
      Adicional, te recomiendo siempre el uso de un Service Bus, para desacoplar las dependencias directas entre sistemas.

      saludos.

  10. Hola Oscar,
    He despejado muchas dudas que tenia con respecto a SOAP y REST. Me puedes compartir un enlace que tenga un ejemplo de como construir un Servicio REST en visual studio 2013, lo apreciaría mucho.
    Gracias!!!

    1. Hola Lisseth, me da gusto que este artículo te aya servidor para resolver tus dudas :), por otra parte, Visual estudio no son tecnologías que yo utilice, por lo que no te puedo recomendar ninguna página, pero creo que bastaría con que goolges un poco y verás que encontrarás algo.

      saludos

  11. Hola Óscar, buen artículo aunque un poco genérico, pero complementado con los comentarios y tus amables respuestas en conjunto este artículo resulta muy útil. Gracias y saludos.

  12. Hola Oscar tu articulo me ayudo mucho para entender varios conceptos, solo tengo una duda para hacer un api rest insertando en tablas maestro-detalle puedo hacerlo en un solo json para que la transaccion sea mas segura e intrega en los datos?? Y otra cosa que me recomoiendas utilizar Angular o C#, para una bd SQL Server??

    1. Hola Julio, muchas gracias por tu comentario.
      Ahora bien, vamos organizando las ideas, para tu primera pregunta referente al maestro-detalle, lo ideal es siempre mandarlos juntos, por que así hacemos todo en un solo paso, ahorrando recursos del lado del servidor y dando tiempos de respuesta más rápidos al usuario, sin embargo, hay te tomar en cuenta que cada aplicación es diferente, por lo que habra algunas en las que no tengas el detalle al momento de crear el maestro, por otro lado, con respecto a la seguridad, el número de peticiones no tiene nada que ver con la seguridad, si no los mecanismos de seguridad que utilices para proteger la comunicación y los datos.
      Finalmente, respecto a Angulas o C#, yo creo que las dos son complementarias, podrías utilizar Angular para crear las vistas ya que es muy bueno para eso, y utilizar C# para crear el API REST, además, SQLServer es bien soportada por todas las tecnologías, así que no debería ser un factor de decisión.

      Una última cosa, si usas Angular, te sugiero darle una revisada a React, para mi gusto es mucho mejor y más simple, te dejo una liga a mi libro y a mi curso gratuito para que les des una revisada.

      1. Muchas gracias por la respuesta, ya me inscribi al curso hoy por la tarde empiezo a revisarlo, una ultima duda estoy haciendo el REST en c# con entity framework pero la verdad estoy atorado en como poder hacer el maestro detalle en un solo paso, tendras algun ejemplo o articulo en el que me pueda apoyar. El api para que la utilizo es para un dispositivo movil asi que si cuento con el detalle y el maestro.

          1. Me ha sido de mucha ayuda gracias, solo que para hacer en el metodo post es donde no encuentro como hacerlo?? Tendras alguna referencia o ejemplo para utilizar esto en post con .NET??

  13. Buenas, me gustaría saber cuál seería lamejor forma de enfocar para mi trabajo de diploma esta comparación, porque cuando expuse la semana pasada no quedó claro para el tribunal el por qué escogía realizar la API con servicios REST. Se quiere hacer esta API basada en microservicios para el módulo de un sistema ya desplegado, el cual se desea migrar con el empleo de API para lograr una escalabilidad,qué usted cree?

    1. Hola Danis,

      Mira, yo me enfocaría en conocer quienes son los consumidores del API y el formato en el que ya están los servicios del sistema desplegado. Solo toma en cuenta que la escalabilidad y la arquitectura de microservicios es perfectamente implementable con SOAP o REST.

      Generalmente en este tipo cosas, lo que más cuenta es que tu misma estés segura de tu decisión, por que el jurado trata de refutar tus argumentos con lo que sea. Al final, SOAP y REST son servicios y pueden ser consumidos donde sea, aun que si tu target es aplicaciones web o móviles, yo me inclinaría por REST.
      saludos.

      1. Muchas gracias!!!, me sirvió mucho su visión porque usted sabe que a veces uno se cierra en estos casos producto del nervio de lo que implica este momento, ya tengo un poco más de seguridad en lo que voy hacer y su artículo me ha servido para profundizar y aclarar más los argumentos en la comparación de mi trabajo.

  14. Buen día Oscar,

    Gracias por publicar tu/s articulo/s que realmente son de muchísima ayuda para todos, quiero que me ayudes con algo que no lo tengo claro, el fin que quiero conseguir es tener en memoria mucha información y que siempre este disponible, actualmente tengo un web service con mis métodos, estos deberían consumir a un servicio soap o rest?, la cuestión es que tengo la idea y no estoy seguro que cuando levanto un servicio SOAP el IIS en mi caso que desarrollo con C# .NET recicla periódicamente al servicio y eliminaría la información subida?, por lo tanto no se aun por donde ir para poder tener algún componente consumible desde mi web service y que siempre contenga la información en memoria (a mas de mantener la información en memoria realiza un procesamiento con la misma dependiente los parámetros que le lleguen desde la invocación que haría desde mi web service). Podrías ayudarme con una idea o camino a seguir para poder tomar la mejor decisión según mi problemática, de ante mano te agradezco y quedo a la espera de tu valiosa opinión.

    Saludos cordiales,

    Camilo Torres N.

    1. Estimado Camilo, debemos partir la problemática en dos cosas, el mecanismos de persistencia y los servicios que expones a internet, dicho esto, la capa de persistencia solo se debería de encargar de guardar la información en memoria/db y la capa se servicios solo se debe de recuperar la información de la DB, en este caso, la pregunta que planteas es confusa, por que no se que es lo que logras resolver, como exponer los servicios (REST, SOAP) o como guardar la información en memoria para no perderla al reiniciar.

      Si me explicas con más claridad te podría ayudar un poco más.
      saludos.

    2. Hola Camilo, yo para resolver eso use una clase con patron Singleton, esa clase la inicializo en el Global.asax, en esa clase la informacion esta siempre, solo se pierde si IIS recicla la aplicacion pero eso se puede controlar desde la configuracion avanzada de Application Pool.

      Recomiento investigar IIS porque mucho del comportamiento en webapps o webservice dependen de como este configurado IIS para la aplicacion.

  15. Muy buen artículo. Sin embargo, para mi hay una diferencia fundamental que no se ha comentado y quisiera saber si piensas igual. Antes quisiera que tuvieras en mente el punto de vista de servicios orientados y no orientados a la conexión ( como en la capa de transporte del modelo TCP/IP). Hasta ahora tenia entendido que los servicios SOAP eran orientados a la conexión al estilo del TCP y los servicios REST eran no orientados a la conexión al estilo de UDP y para mí esa era la gran diferencia. En un servicio SOAP tienes consumiendo un recurso en el servidor porque se establece una conexión que no se libera mientras el cliente esté conectado. Por contra, en un servicio REST se empieza y se acaba con la solicitud REST, pero mientras no realices una llamada REST no consumes recursos del servidor adicionales por cada cliente. Para redes de comunicaciones fiables ( servidores en redes de area local cableadas) no hay ningún inconveniente en mantener servicios SOAP si el servidor tiene recursos porque encima mejora la velocidad de respuesta respecto a REST al tener la linea de comunicación abierta, pero en lineas de comunicación inalámbricas o poco fiables, tener la comunicación abierta es un problema, porque continuamente puedes tener que reconectar el servicio por un corte en la comunicación. ¿Estás de acuerdo o estoy equivocado?

    1. Hola Jose, recuerda que tanto REST como SOAP funcionan con el mismo protocolo, es decir HTTP o HTTPS. Por otro lado, en los dos casos la comunicación se abre y cierra al momento de la ejecución. Con la llegada de HTTP2 si que es posible mantener conexiones abiertas al servidor, pero el consumo de los recursos sería únicamente el de tener el socket abierto, lo que ya hacemos con Websockets, sin embargo, en la actualidad casi no se utiliza HTTP2.
      saludos.

      1. De ahí mi duda. Cuando el navegador realizar una llamada solicitando una página web ahora mismo puede utilizar http 1.1 / 2 (SPDY poco utilizado) / 3 (QUIC en proceso de homologación). Para el usuario es transparente, pero para el navegador no , porque por ejemplo en el caso de http2 deja la conexión TCP abierta para futuras conexiones y se cierra automáticamente al cabo de un tiempo de inactividad.
        En este caso no conozco suficientemente los detalles de la implementación de los webservice, per a mi entender aunque tanto SOAP como REST utilizan http, en el caso de los webservice se deja la sesión abierta al estilo HTTP2, por así decirlo, consumiendo recursos, por eso digo lo de orientado a la conexión. De hecho en aplicaciones que necesitan utilizarse con redes inalámbricas con mala cobertura tengo entendido que se recomienda REST, porque establecer conexión con un webservice requiere un proceso de conexión , mientras que la llamada REST es simplemente invocar la URL con los parámetros adecuados. Por eso mi duda es si podemos considerar los webservice como servicios orientado a la conexión o no.

  16. Hola Oscar, muy bueno, pero no entiendo porque decis que con webservice solo se envia por xml, yo he creado varios webservice con WCF y usando Json. WCF te permite usar el envio por xml como por json con lo cual. el servicio que hice es con wcf net.tcp (dualbinding), que opinas?

    Con respecto al comentario de Jose Ramon, es correcto con WCF net.tcp DualBinding se puede mantener la conexion abierta, para esto es necesario hacer cambios en IIS para poder controlar los tiempos de inactividad. El servicio que hice lo configure para estar 24 hrs conectado.

    SignalR es otra tecnologia que opera como wcf dualbinding, es algo que estoy viendo de a poco, es como algo mas simplificado pero tiene un gran potencial (a diferencia de wcf) porque se puede consumir como cliente en Javascript y aplicaciones clientes con diferentes tipos de aplicaciones (winforms, wpf, webapp, etc).

    saludos!

    1. Hola Pablo, gracias por tu comentario
      Cuando me refiero a webservices, hago referencia a los servicios web tradicionales con SOAP, ahora bien, en este sentido, es verdad que podrías envíar un JSON, por que al final tu envías un mensaje por el protocolo HTTP, sin embargo, una parte del estándar de los webservices con SOAP es el WSDL, el cual es un descritor del mensaje que entra y sale, en este sentido, un JSON no puede ser validado por un XSD lo cual conduciría a tener un Webservices que no cumple su propio contrato, lo cual jamás debería de ser. Con respecto a los servicios web con REST, allí si puedes enviar lo que quieres, xml, text, json, binary, etc.

      Lo de la conexión por 24 horas si me sorprende un poco, jamás había escuchado tal cosa, lo que me hace pensar que en tal caso, la conexión es a nivel de protocolo, es decir HTTP o HTTPS y no precisamente la tecnología, lo que entonces aplicaría para REST pues al final también utiliza HTTP o HTTP.
      Por otra parte, no identifico un escenario donde requiere mantener la conexión abierta. Puedo comprender que mantenerla abierta puede mejorar el performance de las siguientes ejecuciones, pues establecer una conexión http es costosa. Pero en tal caso, podrías utilizar un socket o un websocket, lo cual podría ser mucho mejor, pero en fin, seguramente abra escenarios donde si sea necesario y no logro verlos ahora.

      Agradezco tu comentario

  17. Exelente blog, pude aprender tanto del articulo asi como de los aportes en los comentarios de los lectores.
    Buen trabajo Oscar, saludos desde Toluca, Edomex

  18. Que tal Oscar,

    Muy bueno tu articulo,

    Yo estoy utilizando Oracle Apex (Application Express), y este utiliza Resfull servicess, me estoy conectando con un cliente que tiene REST y necesito consumir el web services para enviar informacion.
    El cliente me esta enviando un Url para el consumo. y lo que estoy enviando es un XML.

    Tu me podrias ayudar a entender el proceso, y que necesito para consumir un web services.

    Saludos

      1. Gracias por tu pronta respuesta,

        Si nuestro cliente tiene un servicio REST, y necesitamos conectarnos a el para enviar informacion por medio de XML’s.

        La generacion de XML ya lo tengo en mi base de datos, ahora necesito poder enviarlo, ellos como te comente nos dieron el URL para poder hacer esta accion.

        Te comento que es mi primera vez conectandome a un servicios REST.

        Si me pudieras guiar lo mas detalladamente posible, te lo agradeceria mucho.

        1. Hola amigo, no es por no querer ayudarte, pero internet hay muchísima más información de como funciona REST de lo que yo podría ayudarte mediante comentarios, mi sugerencia es que te dirijas a la documentación oficial del API que estás utilizando para consumir los servicios, seguramente allí encontrarás todos los detalles, al menos eso es lo que yo aria.

  19. Hola Oscar, no me quedó claro finalmente cómo definir REST.
    Comentas en el artículo que REST es una tecnología, sin embargo en el vídeo “Qué es API REST? – 🚀Y por que es importante aprenderlo” comentas que NO es una tecnología sino una Arquitectura.

    Gracias de antemano.
    Un saludo.

  20. Hola Oscar. me ha parecido muy interesante tu articulo. 🙂

    Yo estoy recien empezando a generar unos servicios web api con .net core y me gustaria consultarte algo que tal vez para ti es una cosa facial y que me ha tenido dos dias si poder resolverla …

    La consulta es: Como dejo “a disposicion para aplicaciones que deseen consultarlo” (o sea: activo y en escucha) a un servicio web api que he desarrollado ?

    En pruebas es facil ya que sencillamente lo ejecuto y luego apunto a esa direccion con los paremetros necesarios … Pero en PRODUCCION …? Como lo disparo y dejo siempre activo ?

    Parece una tonteria la consulta pero no me doy cuenta de como hacerlo.

    Mil gracias.

    1. En producción lo tendrías que ejecutar de la misma forma, lo importante es que tu servidor tenga una IP publica o un dominio para poder alcanzarlo, además, debes de asegurarte de que los puestos que estás utilizando no están bloqueados por el servidor.

  21. Hola Oscar, quisiera saber si podes evacuar una duda que tengo.

    Si yo creo un servicio WCF RESTful, es decir un .svc (con WebGetAttribute), por mas que esté utilizando la arquitectura de REST, ¿el protocolo que está usando es SOAP? Es algo que no llego a terminar de entender, ya que por lo que entiendo un RESTful es un web service que implementa la arquitectura REST , pero no es un servicio REST.

    Muchas Gracias!

    1. Hola Hernan, no he trabajo con WCF, por lo que no se decirte si utiliza REST o nó, lo que puede decir es que si consumes los servicios por medio de los métodos HTTP como GET, POST, DELETE, POST, entonces es muy probable que sea,por otro lado, si tienes que mandar los mensajes a un Endpoint fijo envueltos en SOAP, es un echo que no.
      Saludos.

  22. Buenas noches,
    interesante este post mi estimado Oscar. Estoy ahora implementando una api restfull con slim PHP, para ello empece primero a documentarme sobre los webservices ya que tuve una duda sobre ¿por que algunas veces se implementa el soap y en algunas ocasiones se usa el rest?, con este post aterrice las respuesta y me queda mas claro la diferencia de entre los dos modelos de la arquitectura SOA
    un saludo

  23. A pesar de que ya pasaron 2 años este post sigue siendo bastante útil, incluso la parte de comentarios es bastante interesante como todos plantean sus puntos de vista.

    Muchas gracias Oscar.

    1. En realidad no importa cuanto tiempo ha pasado, los conceptos no cambian con el tiempo. Pero de igual forma, me alegra que el artículo te fue de utilidad.

  24. Me gusto la publicación, y mas que todo por que ya paso mas de dos años y sigue activo los comentarios; creo que el merito es de Oblancarte, dado que responde los comentarios a mas tardar en menos de una semana y muestra interés en ayudar.
    Estoy leyendo varias de tus publicaciones con respecto a Servicios, quiero aprender y me gusta tu Blog.
    Éxitos y sigue adelante, un Feliz año nuevo 2020…!!

    1. Hola Andres, gracias por el comentario.
      Y pues si, la idea de este blog es precisamente ayudar a otros, sobre todo con temas de arquitectura y que luego son complejos de entender 🙂

  25. Excelente material tanto por parte de Oscar como por el aporte de los lectores. A+!
    Me interesa mucho el tema pues sueño con arquitecturas distribuidas desde los tiempos de CORBA, y pues SOA es este sueño hecho realidad 🙂

    1. Hola Gerardo, SOA es muy interesante, pero como estilo arquitectónico ya va en declive, pues todas las empresas han comenzado a migrar a arquitecturas con Microservicios, los cuales también exponen servicios como SOA, pero con la ventaja de que permite crear aplicaciones más distribuidas y con pequeños componentes que tengan solo una responsabilidad, si te interesa a prender tenemos un curso de Desarrollo de Microservicios con Spring Boot o una especialidad de Fullstack con Spring Boot + React, por si quieres aprender bien y dominar la materia, dales una revisada y cualquier duda platicamos.
      saludos 🙂

  26. Hola!!
    Una consulta, desde una aplicación móvil (frontend) se comunica vía webservice a una aplicación core (backend), este webservice puede ser SOAP, como puedo saber si esta comucicación es segura, dado que se trasmiten datos sumamente sensibles?
    Gracias por vuestro tiempo.
    Gabriel

  27. Sumo una nueva consulta, se bebe reemplazar el certificado SSL por un certificado TLS?
    Y como puedo saber que certificado están utilizando actualmente.

    Muchas Gracias
    Gabriel

    1. Hola Gabriel, en realidad TLS es como una nueva versión de SSL, sin embargo, se le siguen llamando certificados SSL. Los certificados son de tipo RSA y los puedes comprar en varias páginas, como Comodo, Namecheap, etc. o puedes hacer unos gratuitos con Letsencrypt,
      saludos.

    1. Selene, PHP tiene herramientas para trabajar con cualquiera de los dos (REST/SOAP) y la decisión depende de tu preferencias. Personalmente utilizo estas condiciones para decidir cuál de ellas utilizar: utiliza SOAP para API’s públicas complejas que requieran que los usuarios de la API puedan validar sus documentos con un diccionario y utiliza REST para API’s internas (en una empresa o grupo “cerrado” de usuarios). Espero que te sea de utilidad. Saludos.

  28. Hola!
    Tengo una tabla que rellenar sobre los conceptos que implican a ambas tecnologías y tengo dudas sobre si lo estoy haciendo bien:
    SOAP REST
    Utiliza siempre el protocolo HTTP para el paso de mensajes NO SI

    Soporta diferentes lenguajes para la representación de la info. NO SI

    Sólo soporta el uso de uno de los métodos de HTTP SI NO

    Es necesario definir un contrato que vincule servidor y cliente SI NO

    El mismo cliente puede emplearse con cualquier servidor SI SI

    Define el formato el que se intercambia la información SI NO

    La inclusión de una nueva operación/recurso en el lado del
    servidor implica cambios en el lado del cliente NO NO

    ¿Podrías corregirme si estoy confundida en algún concepto?
    Muchas gracias!,
    Un saludo

    1. Hola Sara, como te puedo decir si estás bien o mal si no me das las respuestas que tu concideras correctas, necesitas que te lo conteste o que te corriga?

  29. Perdona, la idea era poner mi comentario anterior como una tabla pero no resulto. Necesitaba que me corrigieses, por ejemplo para la primera cuestión ¿Utiliza siempre el protocolo HTTP para el paso de mensajes? Para SOAP tengo claro que NO y para REST que SI, en el otras cuestiones no tengo muy claras mis respuestas (tan solo es decir SI o NO a SOAP o REST).

    Muchas gracias,
    Un saludo!

    1. lo que afirmas es correcto, SOA se puede transmitir por varios protocolos, mientras que REST tiene como restriccón el uso de HTTP, pues si recuerdas, toda la comunicación se hace mediante los verbos HTTP, como es GET, POST, DELETE, PUT, etc.

    1. No comprendí bien tu pregunta, por lo que trataré de responder a como te entendí… Los webservices (SOAP) puede funcionar sin usar HTTP, y cuando lo usan, todas las solicitudes son por el método POST, mientras que REST usa exclusivamente HTTP y puede utilizar cualquiera de los métodos HTTP disponibles.

    1. Pues en realidad es lo mismo, los dos se transpotan por HTTP(TCP/IP), incluso, SOAP se manda siempre por el método POST, así que en realidad puedes aplicar la misma seguridad para los dos

  30. Hola mi nombre es Luis quisiera hacerte una pregunta
    Tengo una base de datos en access la cual quiero consultar en un servicio donde trabajan con SOAP quisiera saber si hay alguna forma de consultar todos los números de forma automática y no ingresándolos de a uno
    Me podrías ayudar con alguna idea desde ya muchas gracias.

  31. De las tres arquitectura vista en clases y en sus trabajo de investigación ¿Cuál de ellas aplicaría? Si Ud. fuera el encargado de implementarla en su trabajo o negocio.

  32. Hola Oscar. Primeramente, quería felicitarte por tu trabajo en el área educativa sobre estos temas. Es poca la cantidad de material de calidad en español que puede encontrarse en la red.
    Luego, quería consultarte sobre una problemática que viene dando vueltas en mi cabeza hace tiempo: tengo que desarrollar una aplicación que se conectará tanto por dispositivos móviles como por un sitio web y una aplicación desktop, motivo por el cual decidí separarlo en capas, delegando la lógica de negocios y el acceso a datos a un servicio web con el objetivo de reutilizar y centralizar estas funcionalidades. Al respecto, te comento que en principio estoy pensando en un servicio Rest, por la rapidez al momento de procesar muchos datos (al economizar con Json), pero no me resulta sencillo diseñar los endpoints, teniendo en cuenta que los procesos de mi aplicación requieren que el servicio provea no solo de CRUDs, sino también operaciones distintas a éstas, como por ejemplo que me devuelva la posición de una caja en un depósito según un algoritmo determinado, calcular impuestos de una factura, etc. No sé si me doy a entender. Posiblemente esté conceptualizando las cosas incorrectamente, pero pareciera que la única manera es encararlo con un servicio Soap, con las desventajas en rendimiento que eso conlleva.
    En resumen ¿Es posible implementar lo planteado en servicios Restful? ¿Podrías orientarme al respecto por favor?
    Muchas Gracias.

    1. Hola Pablo, lo que tu quieres hacer es perfectamente implementable con REST, incluso, yo lo he hecho muchas veces, quizás lo que te falta es una orientación un poco más profunda, por lo que te invito a que veas mi curso de Mastering API REST, verás que en ese curso aprenderás a hacer eso y muchas cosas más. además de poder realizar las preguntas que veas necesarias.

      1. Gracias por tu pronta respuesta Oscar. Si, tengo planeado adquirir este curso, ya que las necesidades de conocimiento que tengo sobre el tema exceden a esta consulta, Lo mismo sucede con los cursos de patrones de diseño y el de arquitectura de software. La necesidad tiene que ver con un plan de carrera profesional que tengo en mente, en la cual dispuse tiempos y objetivos. Sin embargo, en este momento, la situación económica en la que me encuentro no me lo permite.
        Podrías darme alguna orientación sobre el tema, aunque no profundices sobre la misma? Sería de mucha ayuda para avanzar con el proyecto en el que me encuentro actualmente. La idea también es que al optar por el método Rest, su estructura no sea compleja para quien la consume. Por otra parte estaba pensando en GraphQL, pero también debo resolver el agregar las cuestiones relacionadas a la lógica de negocio. Me gustaría que quien consuma la API, no deba preocuparse por la lógica de negocio, tan solo del frontend.
        Muchas gracias nuevamente.
        Un abrazo desde Argentina.

  33. Segun la recomendacion de que SOAP es la mejor opcion por robustez, seguridad, control y validación de sus esquemas en integración de cores bancarios, pasarelas de pago, ect como mencionaban mas arriba, cual seria la alternativa a tener en cuenta actualmente si se encararia desde cero un desarrollo de este tipo?

    Por ejemplo la empresa donde trabajo es una cadena de retail, donde se comunican sucursales entre si, con centros de distribucion, administracion central, etc., que requiere abrirse al exterior como supongo pasa en la mayoria de estos lugares. El desarrollo actual está basado en .net/WCF, la idea seria no salirse de .net, en caso de seguir optando por SOAP, que me recomiendas?

    1. Primero que nada, este artículo que tiene sus años, y mi punto de vista de esto ha cambiado bastante, en la actualidad me inclinaría simpre por REST a menos que exista una necesidad muy puntal de necesitar XML como formato de transmición. Strip es la pasarela de pago más potente de la actualidad y funciona 100% con REST.

Deja un comentario

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