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 y actualizar UDDI (Universal Description, Discovery, and Integration).
Pero SOAP está más estandarizado (por ejemplo, la seguridad).
Entonces, ¿estoy en lo cierto en estos puntos?
Desafortunadamente, hay mucha desinformación y conceptos erróneos en torno a REST. No sólo tu 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 lo intenta) 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. Adelantando 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 del cliente y el servidor. Un cliente SOAP funciona como una aplicación de escritorio personalizada, estrechamente acoplada al servidor. Hay un contrato rígido entre el cliente y el servidor, y se espera que todo se rompa si cualquiera de las partes cambia algo. Se necesitan actualizaciones constantes después de cualquier cambio, pero es más fácil determinar si el contrato se está cumpliendo. Un cliente REST es más parecido 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 se violan los estándares del protocolo creando métodos extra, se aprovechan los métodos estándar y se crean las acciones con ellos en el tipo de medio. Si se hace bien, hay menos acoplamiento, y los cambios pueden ser tratados con más gracia. Se supone que un cliente entra en 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 un conocimiento previo de todo lo que va a utilizar, o ni siquiera comenzará la interacción. Además, un cliente REST puede ampliarse con código a la carta suministrado por el propio servidor, siendo el ejemplo clásico el código JavaScript utilizado para dirigir la interacción con otro servicio en el lado del cliente. Creo que estos son los puntos cruciales para entender en qué consiste REST y en qué se diferencia de SOAP:
stackoverflow.com/questions/<id>
, sustituir id por Question.id y pegar eso en tu navegador. Eso no tiene sentido, pero es lo que mucha gente cree que es REST.
Este último punto no se puede enfatizar lo suficiente. Si tus clientes están construyendo URIs a partir de plantillas en la documentación y no obtienen enlaces en las representaciones de los recursos, eso no es REST. Roy Fielding, el autor de REST, lo dejó claro en esta entrada de blog: Las APIs de REST deben estar orientadas al hipertexto.
Teniendo en cuenta lo anterior, te darás cuenta de que aunque REST no se limita 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. Hay borradores de estándares para JSON, como HAL.
Por último, REST no es para todo el mundo, y una prueba de ello es cómo la mayoría de la gente resuelve muy bien sus problemas con las APIs HTTP que erróneamente llaman REST y nunca se aventuran más allá de eso. REST es difícil de hacer a veces, especialmente al principio, pero se 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 necesitas hacer algo de forma rápida y sencilla, no te molestes en hacer bien REST. Probablemente no es lo que buscas. Si necesitas algo que tendrá que permanecer en línea durante años o incluso décadas, entonces REST es para ti.La pregunta "REST" vs. "SOAP" no es la correcta.
A diferencia de SOAP
, REST
no es un protocolo.
REST es un estilo arquitectónico y un diseño para arquitecturas de software basadas en la red.
Los conceptos de REST
se denominan recursos. La representación de un recurso debe ser sin estado. Se representa a través de algún tipo de medio. Algunos ejemplos de tipos de medios son XML
, JSON
y RDF
. Los recursos son manipulados por los componentes. Los componentes solicitan y manipulan los recursos a través de una interfaz uniforme estándar. En el caso de HTTP, esta interfaz consiste en operaciones HTTP estándar, como GET
, PUT
, POST
y DELETE
.
La pregunta de @Abdulaziz pone de manifiesto el hecho de que REST
y HTTP
se utilizan a menudo conjuntamente. Esto se debe principalmente a la simplicidad de HTTP y a su natural adaptación a los principios de RESTful.
**Comunicación cliente-servidor
Las arquitecturas cliente-servidor tienen una separación de preocupaciones muy marcada. Todas las aplicaciones construidas en el estilo RESTful deben ser también cliente-servidor en principio.
Sin estado
Cada petición del cliente al servidor requiere que su estado esté completamente representado. El servidor debe ser capaz de entender completamente la petición del cliente sin utilizar ningún contexto o estado de sesión del servidor. De ello se deduce que todo el estado debe mantenerse en el cliente.
Caché
Se pueden utilizar restricciones de caché, lo que permite marcar los datos de la respuesta como almacenables o no almacenables en caché. Cualquier dato marcado como almacenable en caché puede ser reutilizado como respuesta a la misma petición 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 hacer de forma aislada. Dichos cambios, no afectarán a la interacción fundamental de los componentes, porque la interfaz uniforme siempre se mantiene inalterada. Una de las desventajas es que uno se queda con la interfaz. Si se pudiera proporcionar una optimización a un servicio específico cambiando la interfaz, no se tiene suerte, ya que REST lo prohíbe. Sin embargo, el lado bueno 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 señalar que un servicio REST es un servicio web, pero un servicio web no es necesariamente un servicio REST.
Consulta este blog post sobre Principios de diseño de REST para obtener más detalles sobre REST y los puntos mencionados anteriormente.
EDIT: actualizar el contenido en base a los comentarios
SOAP (Simple Object Access Protocol) y REST (Representation State Transfer) son ambos hermosos a su manera. Así que no los estoy comparando. En su lugar, estoy tratando de representar la imagen, cuando preferí usar REST y cuando SOAP.
**¿Qué es la carga útil?
Cuando se envían datos por Internet, cada unidad transmitida incluye tanto la información de la cabecera como los datos reales que se envían. La cabecera 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 que recibe el sistema de destino.
Ahora, por ejemplo, tengo que enviar un Telegrama y todos sabemos que la carga útil del telegrama dependerá de algunas palabras.
Así que dime entre estos dos mensajes mencionados abajo, ¿cuál es más barato de enviar?
<name>Arin</name>
o
"name": "Arin"
Sé que tu respuesta será la segunda aunque ambas representen el mismo mensaje la segunda es más barata en cuanto a coste.
Así que estoy tratando de decir que, el envío de datos a través de la red en formato JSON es más barato que el envío en formato XML con respecto a la carga útil.
Aquí está el primer beneficio o ventaja de REST sobre SOAP. SOAP sólo soporta XML, pero REST soporta diferentes formatos como texto, JSON, XML, etc. Y ya sabemos, si usamos Json entonces definitivamente estaremos en mejor lugar con respecto a la carga útil.
Ahora, SOAP sólo soporta XML, pero también tiene sus ventajas.
**¡De verdad! ¿Cómo?
SOAP se apoya en XML de tres maneras Envelope - que define lo que hay en el mensaje y cómo procesarlo.
Un conjunto de reglas de codificación para los tipos de datos y, por último, la disposición de las llamadas al procedimiento y las respuestas recogidas.
Este sobre se envía a través de un transporte (HTTP/HTTPS), y se ejecuta una RPC (Remote Procedure Call), 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 utiliza HTTP/HTTPS. SOAP puede utilizar casi cualquier transporte para enviar la petición pero REST no. Así que aquí tenemos una ventaja de usar SOAP.
Como ya he mencionado en el párrafo anterior "REST utiliza HTTP/HTTPS ", así que profundiza un poco más en estas palabras.
Cuando hablamos de REST sobre HTTP, se heredan todas las medidas de seguridad aplicadas en HTTP, y esto se conoce como seguridad a nivel de transporte y asegura los mensajes sólo mientras están dentro del cable, pero una vez que se entregan al otro lado no se sabe por cuántas etapas tendrán que pasar antes de llegar al punto real donde se procesarán los datos. Y, por supuesto, todas esas etapas podrían utilizar algo diferente a HTTP.** Así que Rest no es completamente más seguro, ¿verdad?
Pero SOAP soporta SSL al igual que REST adicionalmente también soporta WS-Security que añade algunas características de seguridad empresarial. WS-Security ofrece protección desde la creación del mensaje hasta su consumo. Así que 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 es compatible con ACID ni puede proporcionar un commit de dos fases a través de recursos transnacionales distribuidos.
Pero SOAP tiene un soporte completo 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 en dos fases a través de recursos distribuidos.
No estoy sacando ninguna conclusión, pero preferiré el servicio web basado en SOAP mientras la seguridad, las transacciones, etc. sean las principales preocupaciones.
Aquí está el "The Java EE 6 Tutorial" donde han dicho Un diseño RESTful puede ser apropiado cuando se cumplen las siguientes condiciones. Echa un vistazo.
*Espero que hayas disfrutado leyendo mi respuesta.