Este grupo especializado pasados varios días de trabajo y recopilar de datos, hallamos la solución, nuestro deseo es que te resulte útil en tu trabajo.
Solución:
Desafortunadamente, hay mucha información errónea y conceptos erróneos en torno a REST. No solo su pregunta y la respuesta de @cmd reflejan esas, sino que 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 a su alrededor, ya que la gente tiende a llamar a 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 usar un protocolo y métodos estandarizados, y una aplicación tiene que caber 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 se pueden manejar con más elegancia. Se supone que un cliente ingresa a un servicio REST sin ningún conocimiento de la API, excepto por el punto de entrada y el tipo de medio. En SOAP, el cliente necesita conocimientos previos sobre todo lo que va a utilizar, o ni siquiera comenzará la interacción. Además, un cliente REST puede ampliarse mediante código a pedido proporcionado por el propio servidor, siendo el ejemplo clásico 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 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 existe 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 al respecto.
-
REST está tan estandarizado como las piezas que está utilizando. La seguridad y la autenticación en HTTP están estandarizadas, por lo que eso es lo que usa cuando hace 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 brindan patrones de URI para todo lo que puede hacer en una API REST pierden el punto por completo. No solo están documentando algo que se supone que debe seguir el estándar, sino que cuando lo hace, está acoplando el 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 debe hacer REST, en lugar de tener una página de inicio con enlaces a Preguntas y Respuestas, tendríamos una static documentación que explica que para ver una pregunta, debe tomar el URI
stackoverflow.com/questions/, 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 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, lo dejó claro en esta publicación de blog: Las API de REST deben estar impulsadas por hipertexto.
Con lo anterior en mente, te darás cuenta de que, si bien REST podría 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. Hay 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 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 sencilla, no se moleste en hacer DESCANSO correctamente. 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, REST es para usted.
REST vs SOAP es no la pregunta correcta para hacer.
REST, diferente a SOAP es no un protocolo.
REST es un estilo arquitectónico y un diseño para arquitecturas de software basadas en red.
REST los conceptos se conocen como 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 consta de operaciones HTTP estándar, p. Ej. GET, PUT, POST, DELETE.
La pregunta de @ Abdulaziz ilumina el hecho de que REST y HTTP se utilizan a menudo en tándem. 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 de preocupaciones muy distinta. 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é 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 desprende que todo el estado debe mantenerse en el cliente.
Almacenable en caché
Se pueden usar restricciones de caché, lo que permite que los datos de respuesta se marquen como caché o no caché. 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 toda la interacción de 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 realizar de forma aislada. Dichos cambios no afectarán la interacción de los componentes fundamentales porque la interfaz uniforme siempre se mantiene sin cambios. Una desventaja es que está atascado con la interfaz. Si se puede proporcionar una optimización a un servicio específico cambiando la interfaz, no tiene suerte ya que REST lo prohíbe. Sin embargo, en el lado positivo, 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.
Vea esta publicación de blog en Principios de diseño REST para más detalles sobre DESCANSAR y las viñetas mencionadas anteriormente.
EDITAR: actualizar contenido basado en comentarios
JABÓN (Simple Object Access Protocol) y descansar (Transferencia del estado de representación) ambos son hermosos a su manera. 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 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 conocen como 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 Telegrama y todos sabemos que el costo del telegrama dependerá de algunas palabras.
Así que dime entre los dos mensajes que se mencionan a continuación, ¿cuál es más barato de enviar?
Arin
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.
Entonces estoy tratando de decir eso, 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 lo sabemos, 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.
¡En realidad! ¿Cómo?
SOAP se basa en XML de tres formas: 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, finalmente, el diseño de las llamadas a procedimientos y las respuestas recopiladas.
Este sobre se envía a través de un transporte (HTTP / HTTPS) y 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 de la Transporte “genérico” pero REST usa HTTP / HTTPS. SOAP puede usar casi cualquier transporte para enviar la solicitud, pero REST no. Así que aquí tenemos la ventaja de usar SOAP.
Como ya mencioné en el párrafo anterior “REST usa HTTP / HTTPS”, así que profundiza un poco más en estas palabras.
Cuando hablamos de REST sobre HTTP, todas las medidas de seguridad aplicadas HTTP se heredan, y esto se conoce como seguridad a nivel de transporte y protege los mensajes solo mientras está dentro del alambre pero una vez que lo entregaste en el otro lado no 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 más seguro por completo, ¿verdad?
Pero jabon soporta SSL al igual que REST adicionalmente también es compatible con WS-Security que agrega algunas características de seguridad empresarial. WS-Security ofrece protección contra el creación del mensaje a su consumo. Entonces, para la seguridad del nivel de transporte, cualquier laguna que encontremos que se pueda 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 de dos fases a través de recursos transnacionales distribuidos.
Pero SOAP tiene soporte completo para ambos Gestión de transacciones basada en ACID para transacciones de corta duración y gestión de transacciones basada en compensación para transacciones de larga duración. También es compatible compromiso de dos fases en los 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 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.
Si tienes alguna suspicacia o disposición de desarrollar nuestro enunciado eres capaz de escribir una glosa y con deseo lo leeremos.