¿Cuál es el significado actual de SOAP?

51

La última vez que encontré un servicio basado en SOAP fue durante mi pasantía en una empresa financiera en 2013. Ese fue el momento en que comencé mi carrera en TI. Recuerdo haber tenido material de estudio sobre SOAP en uno de mis cursos de ingeniería. Fuera de eso, no he usado mucho SOAP durante mi carrera.

Estoy preguntando esto ya que la pregunta "Diferencia entre SOAP y REST" apareció en una de mis entrevistas recientes. Por lo que sé (y lo que encontré en Google), SOAP es un protocolo con un acoplamiento estrecho entre el cliente y el servidor para el intercambio de información que está estrechamente relacionado con la lógica empresarial. Mientras que REST es una arquitectura sin estado más flexible para la transferencia de datos.

¿Puede alguien corregirme si estoy equivocado acerca de esta diferencia entre SOAP y REST? Además, ¿cuál es el significado actual de SOAP? ¿La gente todavía está desarrollando nuevas API basadas en SOAP, o ahora es principalmente un legado?

Abhas Tandon
fuente
2
ver también: Futuro de SOAP, con REST
mosquito
14
@gnat: Por lo que vale, las respuestas en ambas preguntas son terribles.
Robert Harvey
77
¿Alguna vez viste un servicio REST? Todo lo que veo son "servicios web que finalmente aprendieron lo que significan los verbos HTTP". ¿Por qué de repente llamamos HTTP REST?
Luaan
8
@Luaan: No hay nada repentino al respecto; la gente ha estado abusando del término "DESCANSO" por años.
Lightness compite con Monica el

Respuestas:

59

REST es de hecho un estilo arquitectónico. SOAP es un protocolo de datos. La distinción es importante; No puedes compararlos directamente.

El propósito principal de REST es representar los recursos en Internet y proporcionar mecanismos para descubrirlos. En contraste, SOAP se usa para comunicar datos estructurados entre computadoras, y eso es todo lo que realmente hace.

Tenga en cuenta que en realidad no necesita REST para crear una relación cliente / servidor entre dos computadoras en Internet. Todo lo que necesita es un mecanismo que transfiera JSON o XML, y ni siquiera lo necesita si está dispuesto a ser incompatible con todos los demás.

Sin embargo, SOAP ha caído en desgracia para las nuevas API públicas, aunque todavía se usa comúnmente para aplicaciones B2B porque puede definir un "contrato de datos" con él. Los servicios web JSON tienen la virtud de ser bastante ligeros y flexibles, y dado que Javascript reconoce a JSON de forma nativa, es una opción natural para los navegadores.

Pero nada de eso tiene mucho que ver con REST, realmente.

Lecturas adicionales
¿REST es mejor que SOAP? (buen artículo, a pesar de que incorrectamente llama REST un protocolo).
El modelo de madurez de Richardson

Robert Harvey
fuente
3
Yo diría que la característica principal de los servicios web JSON es exactamente el hecho de que los navegadores tienen poca compatibilidad con XML y SOAP, mientras que tienen (casi) compatibilidad nativa con JSON. SOAP tiene mucho que ofrecer, pero si no puede realizar solicitudes AJAX contra un servicio SOAP, está muerto. Javascript / JSON se convirtió en el mínimo común denominador de internet, por lo que se necesitaría una gran ventaja de no usarlo, y no hay jabón que mucho mejor.
Luaan el
3
@Luaan No diría que los navegadores tienen poca compatibilidad con XML. De hecho, es difícil ser mejor que hacer una HttpRequest XML y acceder a un atributo que tiene un DOM analizado. Es solo que si lo que uno quiere es una estructura de datos típica, y no un documento, JSON es simplemente más adecuado, ya sea que esté en el navegador o en cualquier otro entorno.
André Paramés
44
Todo lo que necesita es un mecanismo que transfiera JSON o XML, y ni siquiera lo necesita si está dispuesto a ser incompatible con todos los demás. -1: Si desea conectar un cliente y un servidor, solo necesita un protocolo arbitrario que ambas partes entiendan que no tiene nada que ver con el uso de xml, JSON o ser compatible con todos los demás. Incluso el uso de json o xml no garantiza que sea compatible con todos o incluso con alguien. Json y xml son solo formatos de datos, nada más.
Paul Wasilewski
66
@PaulWasilewski: Sí, eso es lo que dije. No te obsesiones con las palabras. Hay una razón por la que todos usan JSON; Es un estándar. Usarlo garantiza que estés usando algo que otros puedan reconocer.
Robert Harvey
3
@RobertHarvey, no, no es lo que escribiste, quizás lo dijiste en serio. JSON es estándar, ¿y qué? CSV, Protcol Buffers, BSON está estandarizado, así como muchos otros. Entonces, la razón por la que todos usan JSON es múltiple. E incluso hay algunos que usan JSON porque todos están usando JSON;)
Paul Wasilewski
29

REST es mucho más limitado que SOAP, que es su fuerza y ​​la razón de su popularidad.

En SOAP, el conjunto de operaciones permitidas y el conjunto de tipos de datos permitidos es esencialmente ilimitado. SOAP es un protocolo de procedimiento remoto, que se utiliza para exponer las API locales en la red sin perder fidelidad. Esto hizo que SOAP fuera popular en entornos empresariales donde los complejos sistemas transaccionales necesitaban interactuar a través de la red sin perder fidelidad en el camino. Esta riqueza en la capacidad también es la caída de SOAP, porque hace que las API de SOAP sean tan engorrosas de entender y usar que necesitaban herramientas automatizadas en forma de bibliotecas de cliente WSDL y SOAP para dar sentido a las cosas. Más aún, exponer toda la riqueza del sistema subyacente no es atractivo en las API públicas, donde desea proporcionar abstracciones que le permitan evolucionar el sistema subyacente sin tener que romper o versionar su API.

REST + JSON ganó popularidad específicamente debido a su simplicidad. Define un conjunto limitado de operaciones con un conjunto limitado de tipos de datos, lo que requiere que el diseñador de API diseñe cuidadosamente abstracciones que se ajusten a este vocabulario limitado y realmente piense en la asignación del dominio empresarial a los recursos REST. Una API REST es fácil de entender y fácil de usar sin ninguna herramienta especial. Para una API pública donde sus usuarios de API pueden tener todos los niveles de habilidad y conocimiento, esto es exactamente lo que desea, por lo que todas las API que ve en la web han pasado a REST. SOAP se relega a situaciones empresariales en las que todavía existe el deseo y la necesidad de compartir API complejas entre sistemas. Sin embargo,

Esencialmente, lo que la gente se ha dado cuenta es que el conjunto de restricciones que debe aplicar al diseño de su API para hacer que la API sea lo suficientemente simple y abstracta para que sea mantenible y fácil de usar es exactamente el conjunto de restricciones que introduce REST, que neutraliza efectivamente los SOAP beneficios dejándote solo con sus desventajas. Podría crear una API simplificada con SOAP, pero nunca sería tan fácil de usar como REST, por lo que en la práctica todos eligen REST.

Joeri Sebrechts
fuente
44
El viejo debate sobre tipeo estático versus dinámico, yay: D Neat and hard vs. hacky and simple, la guerra que nunca termina.
Luaan
@Luaan ... y dinámico siempre gana para el intercambio de datos. youtube.com/watch?v=ROor6_NGIWU
Jared Smith el
66
@JaredSmith, estoy en total desacuerdo. Se supone que los contratos deben seguirse, por lo que ambos puntos finales asignan los datos correctamente, si puede hacerlo a través de la publicación de metadatos en lugar de páginas de documentación propensas a errores, ¿por qué no lo haría?
drake7707
1
REST práctico es un protocolo; La tesis y la religión son 'estilo arquitectónico'. Esta respuesta compara correctamente el descanso práctico con el jabón práctico.
bmargulies
1
Su respuesta ya muestra que no comprende REST y su comentario subraya eso.
Paul Wasilewski el
5

No puede comparar REST y SOAP. REST es un estilo arquitectónico, mientras que SOAP es un protocolo.

Desafortunadamente, REST se convirtió coloquialmente en sinónimo de servicio HTTP RESTful, lo que significa una realización de arquitectura de estilo REST con HTTP como protocolo (de aplicación).

REST se basa en los siguientes principios (restricciones y elementos) (entre paréntesis la realización en RESTful HTTP) [1] .

  • Sin estado (HTTP es un protocolo sin estado)
  • Recurso (identificado por URI)
  • Interfaz uniforme (métodos HTTP)
  • Representación (TIPO MIME)
  • HATEOS (hipervínculos)
  • Caché (Caché HTTP)

Por otro lado, mucha gente quiere decir que SOAP es un servicio web basado en WSDL y SOAP que forman parte de la arquitectura del servicio web W3C [2] .

  • SOAP se utiliza como protocolo para intercambiar información (básicamente nombre del método, parámetros, valores de retorno, tipos de datos, ...).
  • WSDL, un lenguaje de definición de interfaz para describir el servicio web.

¿Cuál es el significado actual de SOAP *?

SOAP es un estándar del W3C y se utiliza como formato de intercambio de información en los servicios web del W3C. Esos servicios web fueron, especialmente durante la exageración de las SOA (arquitecturas orientadas a servicios) alrededor de 2008 (+ - 3 años) y (desafortunadamente) todavía se implementan principalmente en aplicaciones empresariales.

Esto tiene varias razones. En aquel entonces, RESTful HTTP no era bien conocido y se entendía mal. Desafortunadamente, todavía no se comprende bien. Mira las otras respuestas.

"[...] REST es mucho más limitado que SOAP [...]".

"El objetivo principal de REST es representar los recursos en Internet [...]".

Además, SOAP (y WSDL) son parte de la pila de protocolos del servicio web W3C que proporciona aún más estándares para implementar un servicio web.

¿La gente todavía está desarrollando nuevas API basadas en SOAP, o ahora es principalmente un legado?

Entonces sí, todavía hay y habrá también en futuros sistemas que estén utilizando SOAP (al menos en sistemas empresariales, principalmente detrás de las puertas). Pero la mayoría está tratando de hacer algún tipo de "DESCANSO" hoy en día.

¿Puede alguien corregirme si estoy equivocado acerca de esta diferencia entre SOAP y REST?

Decir que REST es una arquitectura sin estado más flexible para la transferencia de datos no es una buena explicación. REST, simplemente hablado, es un estilo de arquitectura con restricciones y elementos específicos. Mientras que SOAP es un protocolo de intercambio de información.

Como ya escribí, no puedes compararlos. Pero puede comparar un servicio web RESTful HTTP con un servicio web SOAP / WSDL.

Paul Wasilewski
fuente
"Pero puede comparar un servicio web RESTful HTTP con un servicio web SOAP / WSDL". Pero eso es lo que pide el OP. ¿Alguien ha respondido eso todavía?
RoboJ1M