Pregunta SOAP vs REST (diferencias)


He leído artículos sobre las diferencias entre SOAP y REST como un 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.

  2. REST no está restringido al formato XML. Los servicios web REST pueden enviar texto sin formato, JSON y también XML.

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

Entonces, ¿estoy en lo correcto en estos puntos?


987
2017-11-09 23:11


origen


Respuestas:


Desafortunadamente, hay mucha desinformación y conceptos erróneos sobre REST. No solo tu pregunta y el respuesta por @cmd refleje ésos, pero 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 trata de serlo) y el segundo es un estilo arquitectónico. Esta es probablemente una de las fuentes de confusión a su alrededor, 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 cualquiera de los lados cambia algo. Necesita actualizaciones constantes después de cualquier cambio, pero es más fácil determinar si se sigue 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 debe encajar dentro de eso. No infringe los estándares de protocolo creando 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 tratar con más gracia. Se supone que un cliente debe ingresar a un servicio REST sin 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 utilizará, o incluso no comenzará la interacción. Además, un cliente REST puede ampliarse mediante código a pedido suministrado 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 cómo difiere 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 exista un esquema de URI estandarizado.

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

  • REST es tan estandarizado como las partes que estás usando. La seguridad y la autenticación en HTTP están estandarizadas, por lo que es lo que se usa al hacer 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 sofisticados generadores de documentación que ofrecen patrones URI para todo lo que puede hacer en una API REST se pierden por completo. No solo están documentando algo que se supone que debe seguir el estándar, sino que cuando lo haces, estás conectando al cliente con un momento particular en la evolución de la API, y cualquier cambio en la API debe ser documentado y aplicado, o se romperá

  • REST es el estilo arquitectónico de la web en sí. Cuando ingresa Stack Overflow, sabe qué es un Usuario, una Pregunta y una Respuesta, conoce los tipos de medios y el sitio web le proporciona los enlaces. Una API REST tiene que hacer lo mismo. Si diseñamos la web de la manera en que las personas piensan que debe hacerse REST, 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 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, dejó en claro en esta entrada del blog: Las API REST deben estar basadas en hipertexto.

Con lo anterior en mente, se dará cuenta de que, aunque REST podría no estar restringido a XML, para hacerlo correctamente con cualquier otro formato, deberá 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 ello es la forma en que la mayoría de las personas resuelven sus problemas muy bien con las API HTTP que erróneamente llamaron REST y nunca se aventuran más allá de eso. REST es difícil de hacer algunas veces, especialmente al principio, pero paga a lo largo del tiempo con una evolución más fácil en el lado del servidor y la capacidad de adaptación del cliente a los cambios. Si necesita hacer algo rápida y fácilmente, no se moleste en obtener el REST 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.


1461
2017-11-10 00:45



REST vs SOAP es no la pregunta correcta para preguntar

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, JSONy RDF. Los recursos son manipulados por los componentes. Los componentes solicitan y manipulan recursos a través de una interfaz estándar uniforme. En el caso de HTTP, esta interfaz consiste en operaciones HTTP estándar, p. Ej. GET, PUT, POST, DELETE.

La pregunta de @ Abdulaziz ilumina el hecho de que REST y HTTP a menudo se usan 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 muy clara de preocupaciones. Todas las aplicaciones creadas en el estilo RESTful también deben ser cliente-servidor en principio.

Apátrida

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

Cacheable

Se pueden usar restricciones de caché, lo que permite que los datos de respuesta se marquen como caché o no como caché. Cualquier información marcada 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 se produce 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 pueden realizarse de forma aislada. Tales cambios no afectarán la interacción de los componentes fundamentales porque la interfaz uniforme siempre se mantiene. Una desventaja es que estás 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, el lado positivo es que REST está optimizado para la Web, ¡y por lo tanto, la popularidad de REST sobre HTTP es increíble!

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 enviar en Principios de diseño de REST para más detalles sobre DESCANSO y las balas indicadas anteriormente.

EDITAR: actualizar contenido basado en comentarios


245
2017-11-09 23:19



JABÓN (Simple Object Access Protocol) y descansar (Transferencia de estado de representación) ambos son hermosos en su camino. Entonces no los estoy comparando. En cambio, estoy tratando de representar la imagen, cuando preferí usar REST y SOAP.

¿Qué es la carga útil? 

Cuando los datos se envían a través de Internet, cada unidad transmitida incluye información del encabezado y 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 la carga útil. En general, la carga útil es la información que se transmite 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 mencionados a continuación, ¿cuál es más barato enviar?

<name>Arin</name>

o

"name": "Arin"

Sé que su respuesta será la segunda, aunque representar el mismo mensaje en el segundo mensaje es más económico en relación con el costo.

Así que estoy tratando de decir eso, enviar datos a través de la red en formato JSON es más económico que enviarlo en formato XML con respecto a la carga útil.

Aquí está el primer beneficio o ventajas de REST sobre SOAP. SOAP solo es compatible con XML, pero REST admite diferentes formatos como texto, JSON, XML, etc. Y ya sabemos, si usamos Json, definitivamente estaremos en 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 confía en XML de tres maneras Sobre: ​​define lo que está 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 de procedimiento 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 puede. Entonces 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 a través de HTTP, todas las medidas de seguridad aplicadas HTTP se heredan, y esto se conoce como nivel de transporte de seguridad y protege mensajes solo mientras está dentro del cable pero una vez que lo entregaste del otro lado, no sabes cuántas etapas tendrá que atravesar 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 admite 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 creación del mensaje para su consumo. Entonces, para la seguridad del nivel de transporte, cualquier brecha que encontremos se puede evitar usando WS-Security.

Aparte de eso, como REST está limitado por su protocolo HTTP por lo tanto, el soporte de transacciones no es compatible con ACID ni puede proporcionar una confirmación en dos fases a través de recursos transnacionales distribuidos.

Pero SOAP tiene un soporte integral para ambos Gestión de transacciones basada en ACID para transacciones de corta duración y gestión de transacciones basada en compensaciones para transacciones de larga duración. También es compatible compromiso en dos fases a través de 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 Un diseño RESTful puede ser apropiado cuando se cumplen las siguientes condiciones. Echar un vistazo.

Espero que hayas disfrutado leyendo mi respuesta.


189
2018-06-14 19:48



DESCANSO(REpresentacional STate Transfer)
REST es un estilo arquitectónico. No define tantos estándares como SOAP. REST es para exponer las API públicas (es decir, API de Facebook, API de Google Maps) a través de Internet para manejar las operaciones de CRUD en datos. REST se centra en acceder a los recursos nombrados a través de una única interfaz coherente.

JABÓN(Simplementar Oproyecto UNcceso PAGrotocol)
SOAP trae su propio protocolo y se enfoca en exponer piezas de lógica de aplicación (no datos) como servicios. SOAP expone las operaciones. SOAP se centra en el acceso a las operaciones con nombre, cada operación implementa alguna lógica comercial. Aunque SOAP se conoce comúnmente como servicios web esto es inapropiado. SOAP tiene muy poco o nada que ver con la Web. REST proporciona verdadero servicios web basado en URI y HTTP.

¿Por qué DESCANSAR? 

  • Como REST usa HTTP estándar, es mucho más simple en casi todos los casos.
  • REST es más fácil de implementar, requiere menos ancho de banda y recursos.
  • REST permite muchos formatos de datos diferentes, ya que SOAP solo permite XML.
  • REST permite una mejor compatibilidad con los clientes de navegador debido a su compatibilidad con JSON.
  • REST tiene un mejor rendimiento y escalabilidad. Las lecturas REST pueden almacenarse en caché, las lecturas basadas en SOAP no pueden almacenarse en caché.
  • Si la seguridad no es una preocupación importante y tenemos recursos limitados. O queremos crear una API que sea fácilmente utilizada por otros desarrolladores públicamente, entonces deberíamos ir con REST.
  • Si necesitamos operaciones Stateless CRUD, 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/xml o application/json para POST y /user/1234.json o GET /user/1234.xml olvidar.
  • Los servicios REST deben ser llamados por la aplicación del lado del cliente y no por el usuario final directamente.
  • S T en REST proviene de STate Transfer Usted transfiere el estado en lugar de que el servidor lo almacene, esto hace que los servicios REST sean escalables.

¿Por qué SOAP? 

  • 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 despacio en comparación con REST y no utiliza el mecanismo de caché web.
  • WS-Security: Si bien SOAP admite SSL (al igual que REST), también es compatible con WS-Security, que agrega algunas características de seguridad empresarial.
  • WS-AtomicTransaction: Necesitas transacciones ACID sobre un servicio, vas a 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 se ocupen de 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. Al igual que si estamos creando un servicio web para pasarelas de pago, finanzas y trabajo relacionado con las telecomunicaciones, entonces debemos ir con SOAP ya que aquí se necesita una gran seguridad.

enter image description here

fuente1
fuente2


81
2017-12-08 23:38



Otras respuestas han proporcionado amplias diferencias de puntos y explicado mucho en detalle. Así que me mantendría alejado de ese tipo de respuestas y le preguntaré si todavía está confundido, de ser así, puede que quiera echarle un vistazo a esta simple analogía. enter image description here


60
2018-06-23 05:19



La decisión entre los dos será su primera opción al diseñar un servicio web, por lo que es importante comprender los pros y los contras de los dos. También es importante, en el debate a veces acalorado entre las dos filosofías, separar la realidad de la retórica.

REST fundamentos

  • Todo en REST se considera como un recurso.
  • Cada recurso es identificado por un URI.
  • Utiliza interfaces uniformes. Los recursos se manejan usando operaciones POST, GET, PUT, DELETE que son similares a las operaciones Crear, Leer, Actualizar y Eliminar (CRUD).
  • Ser apátrida Cada solicitud es una solicitud independiente. Cada solicitud del cliente al servidor debe contener toda la información necesaria para comprender la solicitud.
  • Las comunicaciones se realizan a través de representaciones. Por ejemplo, XML, JSON RESTful Web Services. Los servicios web RESTful se basan en métodos HTTP y el concepto de REST. Un servicio web RESTful normalmente define el URI base para los servicios; los tipos MIME admitidos (XML, texto, JSON, definidos por el usuario, ...) y el conjunto de operaciones (POST, GET, PUT, DELETE) que son compatibles.

Fundamentos de SOAP

  • WSDL define el contrato entre el cliente y el servicio y es estático por naturaleza.
  • SOAP crea un protocolo basado en XML sobre HTTP o, a veces, TCP / IP.
  • SOAP describe funciones y tipos de datos.
  • SOAP es un sucesor de XML-RPC y es muy similar, pero describe una forma estándar de comunicarse.
  • Varios lenguajes de programación tienen soporte nativo para SOAP, por lo general lo alimenta con una URL de servicio web y puede llamar a sus funciones de servicio web sin la necesidad de un código específico.
  • Los datos binarios que se envían deben codificarse primero en un formato como codificado en base64.
  • Tiene varios protocolos y tecnologías relacionadas con él: WSDL, XSD, SOAP, WS-Addressing.

SOAP vs REST?

Uno de los principales beneficios de SOAP es que tiene una descripción de servicio WSDL. Puede descubrir el servicio automáticamente y generar un proxy de cliente utilizable a partir de esa descripción del servicio (generar las llamadas de servicio, los tipos de datos necesarios para los métodos, etc.). Tenga en cuenta que con la versión 2.0, WSDL admite todos los verbos HTTP y también se puede utilizar para documentar los servicios RESTful, pero hay una alternativa menos detallada en WADL (Lenguaje de descripción de aplicaciones web) para ese fin.

Con los servicios RESTful, la seguridad de los mensajes es proporcionada por el protocolo de transporte (HTTPS) y es solo de punto a punto. No tiene un sistema de mensajería estándar y espera que los clientes manejen las fallas de comunicación volviendo a intentarlo. SOAP tiene una lógica exitosa / de reintento incorporada y proporciona confiabilidad de extremo a extremo incluso a través de intermediarios SOAP.

Uno de los principales beneficios de RESTful API es que es flexible para la representación de datos, por ejemplo, puede serializar sus datos en formato XML o JSON. Las API RESTful son más limpias o más fáciles de entender porque agregan un elemento de uso de URI estandarizados y le dan importancia al verbo HTTP utilizado (es decir, GET, POST, PUT y DELETE).

Los servicios RESTful también son livianos, es decir, no tienen muchas etiquetas XML adicionales. Para invocar la API RESTful, todo lo que necesita es un navegador o una pila HTTP, y casi todos los dispositivos o máquinas conectados a una red tienen eso.

Ventajas de REST

  • Como REST usa HTTP estándar, es mucho más simple en casi todos los sentidos. Al crear clientes, desarrollar API, la documentación es mucho más fácil de entender, y no hay muchas cosas que REST no sea más fácil / mejor que SOAP.
  • REST permite muchos formatos de datos diferentes, mientras que SOAP solo permite XML. Si bien esto puede parecer que agrega complejidad a REST porque necesita manejar múltiples formatos, en mi experiencia, ha sido bastante beneficioso. JSON generalmente se adapta mejor a los datos y analiza mucho más rápido. REST permite una mejor compatibilidad con los clientes de navegador debido a su compatibilidad con JSON.
  • REST tiene un mejor rendimiento y escalabilidad. Las lecturas de REST pueden almacenarse en caché; Las lecturas basadas en SOAP no se pueden almacenar en caché.
  • Ninguna herramienta costosa requiere interactuar con el servicio web
  • Curva de aprendizaje más pequeña
  • Eficiente (SOAP usa XML para todos los mensajes, REST puede usar formatos de mensaje más pequeños)
  • Rápido (no se requiere un procesamiento extenso)
  • Más cerca de otras tecnologías web en la filosofía del diseño

Ventajas de SOAP

  • WS-Security: Si bien SOAP admite SSL (al igual que REST), también es compatible con WS-Security, que agrega algunas características de seguridad empresarial. Admite identidad a través de intermediarios, no solo punto a punto (SSL). También proporciona una implementación estándar de integridad de datos y privacidad de datos. Llamarlo "Enterprise" no quiere decir que sea más seguro, simplemente admite algunas herramientas de seguridad que los servicios de Internet típicos no necesitan, de hecho, solo se necesitan en algunos escenarios "empresariales".
  • WS-AtomicTransaction: Necesitas transacciones ACID sobre un servicio, vas a necesitar SOAP. Si bien REST admite transacciones, no es tan completo y no cumple con ACID. Afortunadamente, las transacciones ACID casi nunca tienen sentido en Internet. REST está limitado por HTTP, que no puede proporcionar confirmación en dos fases a través de recursos transaccionales distribuidos, pero SOAP puede hacerlo. Las aplicaciones de Internet no necesitan este nivel de confiabilidad transaccional, las aplicaciones empresariales a veces sí lo hacen.
  • WS-ReliableMessaging: Rest no tiene un sistema de mensajería estándar y espera que los clientes se ocupen de las fallas de comunicación volviendo a intentarlo. SOAP tiene una lógica exitosa / de reintento incorporada y proporciona confiabilidad de extremo a extremo incluso a través de intermediarios SOAP.
  • Lenguaje, plataforma y transporte independientes (REST requiere el uso de HTTP)
  • Funciona bien en entornos empresariales distribuidos (REST supone comunicación directa punto a punto)
  • Estandarizado
  • Proporciona extensibilidad de preconstrucción significativa en la forma de los estándares WS
  • Manejo de errores incorporado
  • Automatización cuando se usa con ciertos productos de idiomas

Dónde usar REST 

Las áreas donde REST funciona bien son:

  • Ancho de banda y recursos limitados: recuerde que la estructura de retorno está realmente en cualquier formato (desarrollador definido). Además, se puede usar cualquier navegador porque el enfoque REST utiliza los verbos GET, PUT, POST y DELETE estándar. Nuevamente, recuerde que REST también puede usar el objeto XMLHttpRequest que la mayoría de los navegadores modernos admiten hoy en día, lo que agrega una bonificación de AJAX.
  • operaciones sin estado: si una operación necesita continuar, entonces REST no es el mejor enfoque y SOAP puede encajar mejor. Sin embargo, si necesita operaciones sin estado CRUD (Crear, Leer, Actualizar y Eliminar), entonces REST es.
  • Situaciones de almacenamiento en caché: si la información puede almacenarse en caché debido a la operación sin estado del enfoque REST, esto es perfecto.

Donde usar SOAP

áreas donde SOAP funciona como una gran solución:

  • Procesamiento asincrónico e invocación: si su aplicación necesita un nivel garantizado de confiabilidad y seguridad, SOAP 1.2 ofrece estándares adicionales para garantizar este tipo de operación. Cosas como WSRM - WS-Reliable Messaging.
  • Contratos formales: si ambos lados (proveedor y consumidor) tienen que ponerse de acuerdo sobre el formato de intercambio, entonces SOAP 1.2 proporciona las especificaciones rígidas para este tipo de interacción.
  • Operaciones con estado: si la aplicación necesita información contextual y administración de estado conversacional, SOAP 1.2 tiene la especificación adicional en la estructura de WS para respaldar esas cosas (Seguridad, Transacciones, Coordinación, etc.). Comparativamente, el enfoque REST haría que los desarrolladores construyeran esta plomería personalizada.

43
2018-04-21 11:12



Diferencia entre reposo 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 comercial.
  5. SOAP define estándares que deben seguirse 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 representacional.
  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 comercial.
  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 medidas de seguridad del transporte subyacente.
  8. REST permite diferentes formatos de datos como texto sin formato, HTML, XML, JSON, etc.
  9. REST es más preferido que SOAP.

Para obtener más detalles, consulte aquí


29
2018-03-21 12:47