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:
REST es más dinámico, no es necesario crear ni actualizar UDDI (Descripción, descubrimiento e integración universales).
REST no se limita únicamente 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 cierto en estos puntos?
Desafortunadamente, existe mucha información errónea y conceptos erróneos sobre REST. No solo su pregunta y la respuesta de @cmd las reflejan, sino la mayoría de las preguntas y respuestas 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 al respecto, ya que la gente tiende a llamar REST a cualquier API HTTP que no sea SOAP.
Empujando un poco las cosas y tratando de 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 cualquiera de las partes cambia algo. Necesita actualizaciones constantes después de cualquier cambio, pero es más fácil determinar si se está cumpliendo el contrato.
Un cliente REST se parece más a un navegador. Es un cliente genérico que sabe cómo utilizar 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 acciones con ellos en su tipo de medio. Si se hace correctamente, hay menos acoplamiento y los cambios se pueden abordar con mayor elegancia. Se supone que un cliente ingresa a un servicio REST sin ningún conocimiento de la API, excepto el punto de entrada y el tipo de medio. En SOAP, el cliente necesita conocimientos previos de todo lo que va a utilizar, o ni siquiera iniciará la interacción. Además, un cliente REST se puede ampliar mediante código bajo demanda proporcionado por el propio servidor; el ejemplo clásico es el código JavaScript utilizado para impulsar la interacción con otro servicio en el lado del cliente.
Creo que estos son los puntos cruciales para entender de qué se trata REST y en qué se diferencia de SOAP:
REST es independiente del protocolo. No está acoplado a HTTP. De manera similar a como puedes seguir un enlace ftp en un sitio web, una aplicación REST puede usar cualquier protocolo para el cual exista un esquema URI estandarizado.
REST no es una asignación de métodos CRUD a HTTP. Lea esta respuesta para obtener una explicación detallada al respecto.
REST está tan estandarizado como las piezas que estás utilizando. La seguridad y la autenticación en HTTP están estandarizadas, por lo que eso es lo que se utiliza al realizar REST a través de HTTP.
REST no es REST sin hipermedia y HATEOAS . Esto significa que un cliente sólo conoce el URI del punto de entrada y se supone que los recursos devuelven enlaces que el cliente debe seguir. Esos sofisticados generadores de documentación que brindan patrones de URI para todo lo que puede hacer en una API REST pierden el sentido por completo. No solo documentan algo que se supone que sigue 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 propia web. 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ñáramos la web de la forma en que la gente cree que se debería hacer REST, en lugar de tener una página de inicio con enlaces a Preguntas y Respuestas, tendríamos una documentación estática que explicaría que para ver una pregunta, debe tomar el URI
stackoverflow.com/questions/<id>. reemplace id con Question.id y péguelo en su navegador. Eso es una tontería, pero eso es lo que mucha gente piensa que es REST.
Este último punto no se puede enfatizar lo suficiente. Si sus clientes crean URI a partir de plantillas en la documentación y no obtienen enlaces en las representaciones de recursos, eso no es REST. Roy Fielding, autor de REST, lo dejó claro en esta publicación de blog: las API REST deben estar basadas en hipertexto .
Con lo anterior en mente, te darás cuenta de que si bien REST puede no estar restringido a XML, para hacerlo correctamente con cualquier otro formato tendrás que diseñar y estandarizar algún formato para tus enlaces. Los hipervínculos son estándar en XML, pero no en JSON. Existen borradores de estándares para JSON, como HAL .
Finalmente, REST no es para todos, y una prueba de ello es cómo la mayoría de las personas resuelven muy bien sus problemas con las API HTTP a las 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 vale la pena 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 sencilla, no se moleste en REST correctamente. Probablemente no sea lo que estás buscando. Si necesita algo que deba permanecer en línea durante años o incluso décadas, entonces REST es para usted.
RESTvs noSOAP es la pregunta correcta.
REST, a diferencia de 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, JSONy 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 consta de operaciones HTTP estándar, por ejemplo GET, PUT, POST, DELETE.
La pregunta de @Abdulaziz ilumina el hecho de que RESTy HTTPa menudo se usan en conjunto. Esto se debe principalmente a la simplicidad de HTTP y su correlación muy natural con los principios RESTful.
Principios REST fundamentales
Comunicación cliente-servidor
Las arquitecturas cliente-servidor tienen una separación de preocupaciones muy distinta. Todas las aplicaciones creadas en estilo RESTful también deben ser, en principio, cliente-servidor.
Apátrida
Cada solicitud de cliente al servidor requiere que su estado esté completamente 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. De ello se deduce que todo el estado debe mantenerse en el cliente.
almacenable en caché
Se pueden utilizar restricciones de caché, lo que permite marcar los datos de respuesta como almacenables en caché o no. Cualquier dato marcado como almacenable en caché se puede reutilizar como respuesta a la misma solicitud posterior.
Interfaz uniforme
Todos los componentes deben interactuar a través de una única interfaz uniforme. Dado que toda la interacción de los componentes se produce a través de esta interfaz, la interacción con diferentes servicios es muy sencilla. ¡La interfaz es la misma! Esto también significa que los cambios de implementación se pueden realizar de forma aislada. Dichos cambios no afectarán la interacción de los componentes fundamentales porque la interfaz uniforme siempre permanece sin cambios. Una desventaja es que estás atascado con la interfaz. Si se pudiera proporcionar una optimización a un servicio específico cambiando la interfaz, no tendrá suerte ya que REST lo prohíbe. Sin embargo, el lado positivo es que REST está optimizado para la web, de ahí la 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.
Consulte esta publicación de blog sobre Principios de diseño de REST para obtener más detalles sobre REST y los puntos mencionados anteriormente.
EDITAR: actualizar el contenido según los comentarios
SOAP ( Protocolo simple de acceso a objetos ) y REST ( Transferencia de estado de representación ) son hermosos a su manera. Entonces no los estoy comparando. En cambio, estoy tratando de representar la imagen cuando prefería usar REST y cuando SOAP.
¿Qué es la carga útil?
Cuando los datos se envían a través de 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 coste del telegrama dependerá de unas palabras.
Entonces dime entre estos dos mensajes mencionados a continuación, ¿cuál es más barato de enviar?
<name>Arin</name>
o
"name": "Arin"
Sé que tu respuesta será la segunda aunque ambas representan el mismo mensaje, la segunda es más económica en cuanto a costo.
Entonces 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í te dejamos 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 sólo soporta XML, pero también tiene sus ventajas.
¡En realidad! ¿Cómo?
SOAP se basa en XML de tres maneras: Sobre: 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 a procedimientos y las respuestas recopiladas.
Este sobre se envía mediante 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 utilizar 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" , profundice un poco más en estas palabras.
Cuando hablamos de REST sobre HTTP, todas las medidas de seguridad HTTP aplicadas se heredan, y esto se conoce como seguridad a nivel de transporte y protege los mensajes solo mientras están dentro del cable , pero una vez que los entregas al otro lado no lo sabes. 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 completamente seguro, ¿verdad?
Pero SOAP admite SSL al igual que REST y además también admite WS-Security , que agrega algunas funciones de seguridad empresarial. WS-Security ofrece protección desde la creación del mensaje hasta su consumo . Entonces, para la seguridad a nivel de transporte, cualquier laguna que encontremos se puede evitar usando WS-Security.
Aparte de eso, como REST está limitado por su protocolo HTTP , su soporte de transacciones no cumple con ACID ni puede proporcionar un compromiso de dos fases a través de recursos transnacionales distribuidos.
Pero SOAP tiene soporte integral tanto para la gestión de transacciones basada en ACID para transacciones de corta duración como para la gestión de transacciones basada en compensación para transacciones de larga duración. También admite el compromiso de dos fases en recursos distribuidos .
No estoy sacando 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 dijeron que un diseño RESTful puede ser apropiado cuando se cumplen las siguientes condiciones . Echar un vistazo.
Espero que hayas disfrutado leyendo mi respuesta.
¿SOAP o REST para servicios web?
REST ( Transferencia de estado de presentación RE ) El estado de presentación RE de un objeto que se transfiere es REST, es decir, no enviamos el objeto, enviamos el estado del objeto. REST es un estilo arquitectónico. No define tantos estándares como SOAP. REST sirve 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 consistente.
SOAP ( Protocolo simple de acceso a objetos ) SOAP trae su propio
protocolo y se enfoca en exponer partes de la lógica de la aplicación (no datos) como servicios. SOAP expone operaciones. SOAP se centra en acceder a operaciones nombradas, cada operación implementa alguna lógica empresarial. Aunque comúnmente se hace referencia a SOAP como servicios web, este es un nombre inapropiado. SOAP tiene muy poco o nada que ver con la Web. REST proporciona verdaderos servicios web basados en URI y HTTP.
¿Por qué DESCANSAR?
- Dado que REST utiliza HTTP estándar, es mucho más sencillo 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, mientras que SOAP solo permite XML.
- REST permite un mejor soporte para los clientes del 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 puedan usar fácilmente de forma pública, entonces deberíamos optar por REST.
- Si necesitamos operaciones CRUD sin estado, opte por 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 tipos de medios para el mismo recurso, según el parámetro del encabezado de solicitud "Aceptar" como
application/xmloapplication/jsonpara POST o/user/1234.jsonGET/user/1234.xmlpara GET. - Los servicios REST deben ser llamados por la aplicación del lado del cliente y no directamente por el usuario final.
- ST en REST proviene de la transferencia estatal . Usted 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 mensajes SOAP se procesa más lentamente en comparación con REST y no utiliza un mecanismo de almacenamiento en caché web.
- WS-Security: si bien SOAP admite SSL (al igual que REST), también admite 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 solucionen los fallos de comunicación reintentando.
- Si la seguridad es una preocupación importante y los recursos no son limitados, entonces deberíamos utilizar los servicios web SOAP. Por ejemplo, si estamos creando un servicio web para pasarelas de pago, trabajos relacionados con finanzas y telecomunicaciones, entonces deberíamos utilizar SOAP, ya que aquí se necesita alta seguridad.
fuente1
fuente2
En mi humilde opinión, no se puede comparar SOAP y REST, ya que 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 sobre SOAP y REST .
SOAP define el formato de mensaje basado en XML que las aplicaciones habilitadas para servicios web utilizan para comunicarse entre sí a través de Internet. Para ello, las aplicaciones necesitan un conocimiento previo del contrato del mensaje, los tipos de datos, etc.
REST representa el estado (como recursos) de un servidor a partir de 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.
