SOAP vs REST (diferencias)

He leído artículos sobre las diferencias entre SOAP y REST como protocolo de comunicación de servicios web, pero creo que las mayores ventajas de REST sobre SOAP son:

1. REST es más dinámico, no es necesario crear y actualizar UDDI (Descripción universal, descubrimiento e integración).

2. REST no está restringido solo al formato XML. Los servicios web RESTful pueden enviar texto sin formato / JSON / XML.

Pero SOAP está más estandarizado (por ejemplo, seguridad).

Entonces, ¿estoy en lo correcto en estos puntos?

Desafortunadamente, hay mucha información errónea y conceptos erróneos sobre REST. No solo su pregunta y la respuesta de @cmd reflejan esas, sino que la mayoría de las preguntas y respuestas están relacionadas con el tema en Stack Overflow.

SOAP y REST no se pueden comparar directamente, ya que el primero es un protocolo (o al menos intenta serlo) y el segundo es un estilo arquitectónico. Esta es probablemente una de las fuentes de confusión, ya que las personas tienden a llamar a REST cualquier API HTTP que no sea SOAP.

Empujando un poco las cosas e intentando establecer una comparación, la principal diferencia entre SOAP y REST es el grado de acoplamiento entre las implementaciones de cliente y servidor. Un cliente SOAP funciona como una aplicación de escritorio personalizada, estrechamente acoplada al servidor. Existe un contrato rígido entre el cliente y el servidor, y se espera que todo se rompa si alguna de las partes cambia algo. Necesita actualizaciones constantes después de cualquier cambio, pero es más fácil determinar si se está siguiendo el contrato.

Un cliente REST es más como un navegador. Es un cliente genérico que sabe cómo usar un protocolo y métodos estandarizados, y una aplicación tiene que encajar dentro de eso. No viola los estándares del protocolo al crear métodos adicionales, aprovecha los métodos estándar y crea las acciones con ellos en su tipo de medio. Si se hace bien, hay menos acoplamiento, y los cambios pueden tratarse con más gracia. Se supone que un cliente ingresa a un servicio REST con cero conocimiento de la API, excepto por el punto de entrada y el tipo de medio. En SOAP, el cliente necesita conocimiento previo sobre todo lo que usará, o incluso no comenzará la interacción. Además, un cliente REST puede ampliarse mediante código a pedido suministrado por el propio servidor,

Creo que estos son los puntos cruciales para comprender de qué se trata REST y en qué se diferencia de SOAP:

• REST es independiente del protocolo. No está acoplado a HTTP. Al igual que puede seguir un enlace ftp en un sitio web, una aplicación REST puede usar cualquier protocolo para el que haya un esquema URI estandarizado.

• REST no es una asignación de CRUD a métodos HTTP. Lea esta respuesta para obtener una explicación detallada sobre eso.

• REST está tan estandarizado como las partes que está utilizando. La seguridad y la autenticación en HTTP están estandarizadas, así que eso es lo que usas cuando haces REST sobre HTTP.

• REST no es REST sin hipermedia y HATEOAS . Esto significa que un cliente solo conoce el URI del punto de entrada y se supone que los recursos deben devolver los enlaces que el cliente debe seguir. Esos generadores de documentación sofisticados que dan patrones de URI para todo lo que puede hacer en una API REST pierden el punto por completo. No solo documentan algo que se supone que debe seguir el estándar, sino que cuando lo haces, estás acoplando al cliente a un momento particular en la evolución de la API, y cualquier cambio en la API debe documentarse y aplicarse, o se romperá

• REST es el estilo arquitectónico de la web en sí. Cuando ingresa a Stack Overflow, sabe qué son un Usuario, una Pregunta y una Respuesta, conoce los tipos de medios y el sitio web le proporciona los enlaces a ellos. Una API REST tiene que hacer lo mismo. Si diseñamos la web de la forma en que las personas piensan que REST debería hacerse, en lugar de tener una página de inicio con enlaces a Preguntas y Respuestas, tendríamos una documentación estática que explica que para ver una pregunta, debe tomar el URI stackoverflow.com/questions/<id>, reemplace id con el Question.id y péguelo en su navegador. Eso no tiene sentido, pero eso es lo que mucha gente piensa que es REST.

Este último punto no puede enfatizarse lo suficiente. Si sus clientes están creando URI a partir de plantillas en la documentación y no obtienen enlaces en las representaciones de recursos, eso no es REST. Roy Fielding, el autor de REST, dejó en claro en esta publicación de blog: las API de REST deben estar impulsadas por el hipertexto .

Teniendo en cuenta lo anterior, se dará cuenta de que si bien REST podría no estar restringido a XML, para hacerlo correctamente con cualquier otro formato, tendrá que diseñar y estandarizar algún formato para sus enlaces. Los hipervínculos son estándar en XML, pero no en JSON. Hay proyectos de estándares para JSON, como HAL .

Finalmente, REST no es para todos, y una prueba de eso es cómo la mayoría de las personas resuelve muy bien sus problemas con las API HTTP que erróneamente llamaron REST y nunca se aventuran más allá de eso. REST es difícil de hacer a veces, especialmente al principio, pero paga con el tiempo con una evolución más fácil en el lado del servidor y la resistencia del cliente a los cambios. Si necesita hacer algo de forma rápida y fácil, no se preocupe por hacer que REST sea correcto. Probablemente no sea lo que estás buscando. Si necesita algo que tendrá que permanecer en línea durante años o incluso décadas, entonces REST es para usted.

RESTvs noSOAP es la pregunta correcta para hacer.

REST, a diferencia noSOAP es un protocolo.

RESTes un estilo arquitectónico y un diseño para arquitecturas de software basadas en red.

RESTLos conceptos se denominan recursos. Una representación de un recurso debe ser apátrida. Se representa a través de algún tipo de medio. Algunos ejemplos de tipos de medios incluyen XML, JSON, y RDF. Los recursos son manipulados por componentes. Los componentes solicitan y manipulan recursos a través de una interfaz uniforme estándar. En el caso de HTTP, esta interfaz se compone de ops HTTP estándar por ejemplo GET, PUT, POST, DELETE.

La pregunta de @ Abdulaziz ilumina el hecho de que RESTy a HTTPmenudo se usan en conjunto. Esto se debe principalmente a la simplicidad de HTTP y su mapeo muy natural a los principios RESTful.

Principios fundamentales de REST

Comunicación cliente-servidor

Las arquitecturas cliente-servidor tienen una separación muy clara de preocupaciones. Todas las aplicaciones creadas en el estilo RESTful también deben ser, en principio, cliente-servidor.

Apátrida

Cada solicitud de cliente al servidor requiere que su estado esté totalmente representado. El servidor debe poder comprender completamente la solicitud del cliente sin utilizar ningún contexto de servidor o estado de sesión del servidor. Se deduce que todo el estado debe mantenerse en el cliente.

Caché

Se pueden usar restricciones de caché, lo que permite que los datos de respuesta se marquen como almacenables o no almacenables. Cualquier dato marcado como almacenable en caché puede reutilizarse como respuesta a la misma solicitud posterior.

Interfaz uniforme

Todos los componentes deben interactuar a través de una única interfaz uniforme. Debido a que la interacción de todos los componentes ocurre a través de esta interfaz, la interacción con diferentes servicios es muy simple. ¡La interfaz es la misma! Esto también significa que los cambios de implementación se pueden hacer de forma aislada. Dichos cambios no afectarán la interacción de componentes fundamentales porque la interfaz uniforme siempre no cambia. Una desventaja es que está atascado con la interfaz. Si se pudiera proporcionar una optimización a un servicio específico cambiando la interfaz, no tiene suerte ya que REST lo prohíbe. En el lado positivo, sin embargo, REST está optimizado para la web, por lo tanto, ¡increíble popularidad de REST sobre HTTP!

Los conceptos anteriores representan características definitorias de REST y diferencian la arquitectura REST de otras arquitecturas como los servicios web. Es útil tener en cuenta que un servicio REST es un servicio web, pero un servicio web no es necesariamente un servicio REST.

Ver este blog puesto en principios de diseño REST para más detalles sobre REST y las balas por encima establecidos.

EDITAR: actualizar contenido basado en comentarios

SOAP ( Protocolo simple de acceso a objetos ) y REST ( Transferencia de estado de representación ) son hermosos en su forma. Entonces no los estoy comparando. En cambio, estoy tratando de representar la imagen, cuando preferí usar REST y cuando SOAP.

¿Qué es la carga útil?

Cuando los datos se envían por Internet, cada unidad transmitida incluye tanto la información del encabezado como los datos reales que se envían. El encabezado identifica el origen y el destino del paquete, mientras que los datos reales se denominan carga útil . En general, la carga útil son los datos que se transportan en nombre de una aplicación y los datos recibidos por el sistema de destino.

Ahora, por ejemplo, tengo que enviar un Telegram y todos sabemos que el costo del telegrama dependerá de algunas palabras.

Entonces, dime entre los dos mensajes mencionados a continuación, ¿cuál es más barato de enviar?

<name>Arin</name>

o

"name": "Arin"

Sé que su respuesta será la segunda, aunque ambas representan el mismo mensaje, la segunda es más barata en cuanto a costo.

Así que estoy tratando de decir que enviar datos a través de la red en formato JSON es más barato que enviarlos en formato XML con respecto a la carga útil .

Aquí está el primer beneficio o ventajas de REST sobre SOAP . SOAP solo admite XML, pero REST admite diferentes formatos como texto, JSON, XML, etc. Y ya sabemos que si usamos Json, definitivamente estaremos en un mejor lugar con respecto a la carga útil.

Ahora, SOAP admite el único XML, pero también tiene sus ventajas.

¡De Verdad! ¿Cómo?

SOAP se basa en XML de tres maneras Envelope: eso define qué hay en el mensaje y cómo procesarlo.

Un conjunto de reglas de codificación para tipos de datos y, finalmente, el diseño de las llamadas y respuestas de procedimiento reunidas.

Este sobre se envía a través de un transporte (HTTP / HTTPS), se ejecuta una RPC (llamada a procedimiento remoto) y el sobre se devuelve con información en un documento con formato XML.

El punto importante es que una de las ventajas de SOAP es el uso del transporte "genérico", pero REST usa HTTP / HTTPS . SOAP puede usar casi cualquier transporte para enviar la solicitud, pero REST no. Entonces aquí tenemos la ventaja de usar SOAP.

Como ya mencioné en el párrafo anterior "REST usa HTTP / HTTPS" , así que profundice un poco en estas palabras.

Cuando hablamos de REST sobre HTTP, todas las medidas de seguridad aplicadas HTTP se heredan, y esto se conoce como seguridad de nivel de transporte y asegura los mensajes solo mientras está dentro del cable, pero una vez que lo entregó al otro lado, no sabe cuántas etapas tendrá que pasar antes de llegar al punto real donde se procesarán los datos. Y, por supuesto, todas esas etapas podrían usar algo diferente a HTTP. Entonces el descanso no es más seguro por completo, ¿verdad?

Pero SOAP es compatible con SSL al igual que REST; además , también es compatible con WS-Security, que agrega algunas características de seguridad empresarial. WS-Security ofrece protección desde la creación del mensaje hasta su consumo . Entonces, para la seguridad de nivel de transporte, cualquier laguna que encontramos que se puede evitar usando WS-Security.

Aparte de eso, como REST está limitado por su protocolo HTTP, por lo que su soporte de transacciones no es compatible con ACID ni puede proporcionar un compromiso en dos fases a través de recursos transnacionales distribuidos.

Pero SOAP tiene soporte integral tanto para la gestión de transacciones basadas en ACID para transacciones de corta duración como para la gestión de transacciones basadas en compensación para transacciones de larga duración. También es compatible con el compromiso de dos fases en los recursos distribuidos .

No estoy llegando a ninguna conclusión, pero preferiré el servicio web basado en SOAP, mientras que la seguridad, las transacciones, etc. son las principales preocupaciones.

Aquí está el "Tutorial de Java EE 6" donde han dicho que un diseño RESTful puede ser apropiado cuando se cumplen las siguientes condiciones . Echar un vistazo.

Espero que hayas disfrutado leyendo mi respuesta.

RESTO ( RE de presentación S tate T ransferencia)
RE de presentación S tate de un objeto es T ransferred es descanso, es decir, no enviamos objeto, enviamos estado de objeto. REST es un estilo arquitectónico. No define tantos estándares como SOAP. REST es para exponer API públicas (es decir, API de Facebook, API de Google Maps) a través de Internet para manejar operaciones CRUD en datos. REST se centra en acceder a recursos nombrados a través de una única interfaz coherente.

De SOAP ( S imple O bject A ccess P ROTOCOLO)
de SOAP trae su propio protocolo y se centra en la exposición de piezas de lógica de la aplicación (no datos) como servicios. SOAP expone operaciones. SOAP se centra en acceder a operaciones con nombre, cada operación implementa cierta lógica empresarial. Aunque SOAP se conoce comúnmente como servicios web, esto es incorrecto. SOAP tiene muy poco que ver con la Web. REST proporciona verdaderos servicios web basados ​​en URI y HTTP.

¿Por qué descansar?

• Dado que REST usa HTTP estándar, es mucho más simple en casi todos los sentidos.
• REST es más fácil de implementar, requiere menos ancho de banda y recursos.
• REST permite muchos formatos de datos diferentes donde SOAP solo permite XML.
• REST permite un mejor soporte para clientes de navegador debido a su soporte para JSON.
• REST tiene mejor rendimiento y escalabilidad. Las lecturas REST se pueden almacenar en caché, las lecturas basadas en SOAP no se pueden almacenar en caché.
• Si la seguridad no es una preocupación importante y tenemos recursos limitados. O queremos crear una API que otros desarrolladores utilicen fácilmente públicamente, entonces deberíamos usar REST.
• Si necesitamos operaciones CRUD sin estado, entonces vaya con REST.
• REST se usa comúnmente en redes sociales, chat web, servicios móviles y API públicas como Google Maps.
• El servicio RESTful devuelve varios MediaTypes para el mismo recurso, dependiendo del parámetro de encabezado de solicitud "Aceptar" como application/xmlo application/jsonpara POST y / /user/1234.jsono GET /user/1234.xmlpara GET.
• Los servicios REST deben ser llamados por la aplicación del lado del cliente y no por el usuario final directamente.
• ST en REST proviene de S tate T ransfer. Transfiere el estado en lugar de que el servidor lo almacene, esto hace que los servicios REST sean escalables.

¿Por qué jabón?

• SOAP no es muy fácil de implementar y requiere más ancho de banda y recursos.
• La solicitud de mensaje SOAP se procesa más lentamente en comparación con REST y no utiliza el mecanismo de almacenamiento en caché web.
• WS-Security: aunque SOAP es compatible con SSL (al igual que REST), también es compatible con WS-Security, que agrega algunas características de seguridad empresarial.
• WS-AtomicTransaction: Necesita transacciones ACID sobre un servicio, necesitará SOAP.
• WS-ReliableMessaging: si su aplicación necesita procesamiento asincrónico y un nivel garantizado de confiabilidad y seguridad. Rest no tiene un sistema de mensajería estándar y espera que los clientes traten con las fallas de comunicación volviendo a intentarlo.
• Si la seguridad es una preocupación importante y los recursos no están limitados, entonces debemos usar los servicios web SOAP. Por ejemplo, si estamos creando un servicio web para pasarelas de pago, trabajo financiero y relacionado con las telecomunicaciones, entonces deberíamos usar SOAP, ya que aquí se necesita una alta seguridad.

Source1
source2

Diferencia entre descanso y jabón

JABÓN

1. SOAP es un protocolo.
2. SOAP significa Protocolo simple de acceso a objetos.
3. SOAP no puede usar REST porque es un protocolo.
4. SOAP utiliza interfaces de servicios para exponer la lógica empresarial.
5. SOAP define los estándares que se deben seguir estrictamente.
6. SOAP requiere más ancho de banda y recursos que REST.
7. SOAP define su propia seguridad.
8. SOAP solo permite el formato de datos XML.
9. SOAP es menos preferido que REST.

DESCANSO

1. REST es un estilo arquitectónico.
2. REST significa Transferencia de Estado representativa.
3. REST puede usar servicios web SOAP porque es un concepto y puede usar cualquier protocolo como HTTP, SOAP.
4. REST usa URI para exponer la lógica empresarial.
5. REST no define demasiados estándares como SOAP.
6. REST requiere menos ancho de banda y recursos que SOAP.
7. Los servicios web RESTful heredan las medidas de seguridad del transporte subyacente.
8. REST permite diferentes formatos de datos, como texto sin formato, HTML, XML, JSON, etc.
9. RESTO más preferido que SOAP.

Para más detalles ver aquí

En mi humilde opinión, no puedes comparar SOAP y REST donde esas son dos cosas diferentes.

SOAP es un protocolo y REST es un patrón arquitectónico de software. Hay muchos conceptos erróneos en Internet para SOAP vs REST .

SOAP define el formato de mensaje basado en XML que las aplicaciones habilitadas para servicios web usan para comunicarse entre sí a través de Internet. Para hacer eso, las aplicaciones necesitan conocimiento previo del contrato de mensaje, tipos de datos, etc.

REST representa el estado (como recursos) de un servidor desde una URL. No tiene estado y los clientes no deben tener conocimientos previos para interactuar con el servidor más allá de la comprensión de hipermedia.

En primer lugar: oficialmente, la pregunta correcta sería web services + WSDL + SOAPvs REST.

Porque, aunque el servicio web , se usa en sentido laxo, cuando se usa el protocolo HTTP para transferir datos en lugar de páginas web, oficialmente es una forma muy específica de esa idea. Según la definición, REST no es "servicio web".

En la práctica, sin embargo, todo el mundo ignora eso, así que vamos a ignorarlo también.

Ya hay respuestas técnicas, por lo que intentaré proporcionar alguna intuición.

Digamos que desea llamar a una función en una computadora remota, implementada en algún otro lenguaje de programación (esto a menudo se llama llamada a procedimiento remoto / RPC ). Suponga que esa función se puede encontrar en una URL específica, proporcionada por la persona que la escribió. Debe (de alguna manera) enviarle un mensaje y obtener alguna respuesta. Entonces, hay dos preguntas principales a considerar.

• ¿Cuál es el formato del mensaje que debe enviar?
• ¿Cómo se debe llevar el mensaje de ida y vuelta?

Para la primera pregunta, la definición oficial es WSDL . Este es un archivo XML que describe, en formato detallado y estricto, cuáles son los parámetros, cuáles son sus tipos, nombres, valores predeterminados, el nombre de la función que se llamará, etc. Un ejemplo de WSDL aquí muestra que el archivo es humano legible (pero no fácilmente).

Para la segunda pregunta, hay varias respuestas. Sin embargo, el único utilizado en la práctica es SOAP . Su idea principal es: envolver el XML anterior (el mensaje real) en otro XML (que contiene información de codificación y otras cosas útiles) y enviarlo a través de HTTP. El método POST del HTTP se usa para enviar el mensaje, ya que siempre hay un cuerpo .

La idea principal de todo este enfoque es que asigne una URL a una función , es decir, a una acción . Entonces, si tiene una lista de clientes en algún servidor y desea ver / actualizar / eliminar uno, debe tener 3 URLS:

• myapp/read-customer y en el cuerpo del mensaje, pase la identificación del cliente a leer.
• myapp/update-customer y en el cuerpo, pase la identificación del cliente, así como los nuevos datos
• myapp/delete-customer y la identificación en el cuerpo

El enfoque REST ve las cosas de manera diferente. Una URL no debe representar una acción, sino una cosa (llamada recurso en la jerga REST). Dado que el protocolo HTTP (que ya estamos usando) admite verbos, use esos verbos para especificar qué acciones realizar en la cosa.

Entonces, con el enfoque REST, el cliente número 12 se encontraría en la URL myapp/customers/12. Para ver los datos del cliente, debe presionar la URL con una solicitud GET. Para eliminarlo, la misma URL, con un verbo DELETE. Para actualizarlo, nuevamente, la misma URL con un verbo POST y el nuevo contenido en el cuerpo de la solicitud.

Para obtener más detalles sobre los requisitos que debe cumplir un servicio para ser considerado realmente RESTful, consulte el modelo de madurez de Richardson . El artículo da ejemplos y, lo que es más importante, explica por qué un servicio (llamado) SOAP es un servicio REST de nivel 0 (aunque, nivel 0 significa bajo cumplimiento de este modelo, no es ofensivo y sigue siendo útil en muchos casos).

Entre muchos otros ya cubiertos en las muchas respuestas, destacaría que SOAP permite definir un contrato, el WSDL, que define las operaciones admitidas, los tipos complejos, etc. SOAP está orientado a las operaciones, pero REST está orientado a los recursos. Personalmente, seleccionaría SOAP para interfaces complejas entre aplicaciones empresariales internas, y REST para interfaces públicas, más simples y sin estado con el mundo exterior.

Adición para:

++ Un error que a menudo se comete al acercarse a REST es pensar en él como "servicios web con URL"; pensar en REST como otro mecanismo de llamada a procedimiento remoto (RPC), como SOAP, pero invocado a través de URL HTTP simples y sin el fuerte SOAP Espacios de nombres XML.

++ Por el contrario, REST tiene poco que ver con RPC. Mientras que RPC está orientado al servicio y enfocado en acciones y verbos, REST está orientado a los recursos, enfatizando las cosas y los sustantivos que comprenden una aplicación.

Muchas de estas respuestas olvidaron por completo mencionar los controles hipermedia (HATEOAS), que es completamente fundamental para REST. Algunos otros lo tocaron, pero realmente no lo explicaron tan bien.

Este artículo debería explicar la diferencia entre los conceptos, sin entrar en las malas hierbas en características SOAP específicas.