Rest vs. Soap. ¿REST tiene un mejor rendimiento?

Question

He leído algunas preguntas ya publicadas aquí con respecto a Soap and Rest y no he encontrado la respuesta que estoy buscando. Tenemos un sistema que se ha creado utilizando los servicios web de Soap. El sistema no es muy eficiente y está en discusión para reemplazar todos los servicios web de Soap para los servicios web REST. Alguien ha argumentado que Rest tiene un mejor rendimiento. No sé si esto es cierto. (Esta fue mi primera pregunta) Suponiendo que esto sea cierto, ¿hay alguna desventaja al usar REST en lugar de Soap? (¿Estamos perdiendo algo?)

Gracias de antemano.

Answer 1

El rendimiento es un tema amplio.

Si se refiere a la carga del servidor, REST tiene un rendimiento un poco mejor porque tiene una sobrecarga mínima sobre HTTP. Por lo general, SOAP trae consigo una pila de manejadores y analizadores (generados) diferentes. De todos modos, la diferencia de rendimiento en sí misma no es tan grande, pero el servicio RESTful es más fácil de ampliar ya que no tiene sesiones del lado del servidor.

Si se refiere al rendimiento de la red (es decir, ancho de banda), REST tiene un rendimiento mucho mejor. Básicamente, es solo HTTP. Sin gastos generales Por lo tanto, si su servicio se ejecuta sobre HTTP de todos modos, no puede obtener mucho más delgado que REST. Además, si codifica sus representaciones en JSON (a diferencia de XML), ahorrará muchos más bytes.

En resumen, yo diría que "sí", tendrá más rendimiento con REST. Además, (en mi opinión) hará que su interfaz sea más fácil de consumir para sus clientes. Por lo tanto, no solo su servidor se vuelve más delgado sino también el cliente.

Sin embargo, un par de cosas a tener en cuenta (ya que lo preguntas '¿qué vas a perder?'):

las interfaces REST tienden a ser un poco más "hablador", así que dependiendo de su dominio y cómo diseñar su recursos, puede terminar haciendo más solicitudes HTTP.

SOAP tiene un soporte de herramienta muy amplio. Por ejemplo, a los consultores les encanta porque pueden usar herramientas para definir la interfaz y generar el archivo wsdl y a los desarrolladores les encanta porque pueden usar otro conjunto de herramientas para generar todo el código de red de ese archivo wsdl. Además, XML como representación tiene esquemas y validadores, que en algunos casos pueden ser un problema clave. (JSON y REST tienen cosas similares por venir pero el soporte de la herramienta está muy atrás)

Answer 2

Definitivamente no soy un experto cuando se trata de SOAP vs REST, pero la única diferencia de rendimiento que conozco es que SOAP tiene una gran sobrecarga al enviar/recibir paquetes, ya que está basado en XML, requiere un encabezado SOAP etc. REST usa el URL + querystring para realizar una solicitud y, por lo tanto, no envía tantos kB a través del cable.

Estoy seguro de que hay otros PPL aquí en la SO que le puede dar respuestas mejores y más detallados, pero al menos lo intentó;)

Answer 3

de SOAP requiere un mensaje XML que ser analizado y todo lo que < riduculouslylongnamespace: mylongtagname> extra </riduculouslylongnamespace: mylongtagname> cosas que se enviarán y recibirán.

REST usualmente usa algo mucho más escueto y fácil de analizar como JSON.

Sin embargo, en la práctica la diferencia no es tan buena.

La creación de un DOM a partir de XML suele realizarse mediante una superrápida pieza de código superoptimizada como XERCES en C++ o Java, mientras que la mayoría de los analizadores JSON están en el rollo propio o en la categoría interpretada.

En un entorno de red rápido (LAN o banda ancha) no hay mucha diferencia entre enviar una o dos K ​​en comparación con 10 a 15 k.

Answer 4

Solo para agregar un poco a la respuesta de wuher.

cabecera HTTP de bytes cuando se solicita esta página usando el navegador web Chrome: 761
bytes necesarios para el mensaje de jabón muestra en wikipedia artículo: 299

Mi conclusión: No es el tamaño de bytes en el cable que permite que REST funcione bien.

Es muy poco probable que simplemente la conversión de un servicio SOAP a REST obtenga importantes beneficios de rendimiento. La ventaja de REST es que si sigue las restricciones, puede aprovechar los mecanismos que HTTP proporciona para producir sistemas escalables. El almacenamiento en caché y el particionamiento son las herramientas en su toolbelt.

Answer 5

Expresa la pregunta como si REST y SOAP fueran intercambiables en algún sistema existente. Ellos no son.

Cuando utiliza SOAP (una tecnología), generalmente tiene un sistema que está definido en 'métodos', ya que en realidad se trata de RPC.

Cuando utiliza REST (un estilo arquitectónico, no una tecnología), entonces está creando un sistema que está definido en términos de 'recursos' y nada en los métodos. No hay correspondencia 1: 1 entre SOAP y REST. La arquitectura del sistema es fundamentalmente diferente.

¿O simplemente está hablando de "RPC vía URI", que a menudo se confunde con REST?

Answer 6

Todo depende. REST realmente no tiene una (buena) respuesta para la situación donde los datos de solicitud pueden volverse grandes. Siento este punto si a veces se pasa por alto al promocionar REST.

Imaginemos un servicio que le permite solicitar datos informativos para miles de artículos diferentes.

El desarrollador de SOAP definiría un método que le permitiría recuperar la información para uno o tantos elementos como desee ... en una sola llamada.

El desarrollador de REST estaría preocupado de que su URI fuera demasiado largo para que definiera un método GET que tomaría un solo elemento como parámetro. Tendría que llamar esto varias veces, una vez por cada elemento, para obtener sus datos. Limpio y fácil de entender ... pero.

En este caso, se necesitarían muchos más viajes de ida y vuelta para que el servicio REST logre lo que se puede hacer con una sola llamada en el servicio SOAP.

Sí, sé que hay soluciones para cómo manejar datos de solicitudes grandes en el escenario REST. Por ejemplo, puede empacar cosas en el cuerpo de su solicitud. Pero luego deberá definir cuidadosamente (tanto en el servidor como en el lado del cliente) cómo debe interpretarse esto. En estas situaciones, comienza a sentir el dolor de que REST no es realmente un estándar (como SOAP) sino más bien una manera de hacer las cosas.

Para situaciones donde solo se intercambia una cantidad relativamente limitada de datos, REST es una muy buena opción. Al final del día, esta es la mayoría de los casos de uso.

Answer 7

Una cosa que las otras respuestas parecen pasar por alto es la compatibilidad con REST para el almacenamiento en caché y otras ventajas de HTTP. Si bien SOAP usa HTTP, no aprovecha la infraestructura de soporte de HTTP. El enlace SOAP 1.1 solo define el uso del verbo POST. Esto se corrigió con la versión 1.2 con la introducción de enlaces GET, sin embargo, esto puede ser un problema si se usa la versión anterior o si no se usan los enlaces apropiados.

La seguridad es otra preocupación clave de rendimiento. Las aplicaciones REST generalmente usan TLS u otros mecanismos de seguridad de capa de sesión. TLS es mucho más rápido que el uso de mecanismos de seguridad de nivel de aplicación como WS Security (WS Security también sufre de security flaws).

Sin embargo, creo que estos son problemas menores cuando se comparan los servicios basados ​​en SOAP y REST. Puede encontrar soluciones para problemas de rendimiento de SOAP o REST. Mi opinión personal es que ni SOAP ni REST (por REST me refiero a los servicios REST basados ​​en HTTP) son apropiados para los servicios que requieren alto rendimiento y baja latencia. Para esos tipos de servicios, probablemente desee utilizar algo como Apache Thrift, 0MQ o la miríada de otros protocolos RPC binarios.

Answer 8

En general, se prefiere un servicio web basado en REST debido a su simplicidad, rendimiento, escalabilidad y compatibilidad con múltiples formatos de datos. SOAP se ve favorecido cuando el servicio requiere soporte integral para seguridad y confiabilidad transaccional.

La respuesta realmente depende de los requisitos funcionales y no funcionales. Hacer las preguntas que figuran a continuación lo ayudará a elegir.

Ref: http://java-success.blogspot.ca/2012/02/java-web-services-interview-questions.html

¿El servicio se exponen datos o lógica de negocio? (RESTO es una mejor opción para exponer datos, SOAP WS podría ser una mejor opción para la lógica). ¿Los consumidores y los proveedores de servicios requieren un contrato formal? (SOAP tiene un contrato formal a través de WSDL) ¿Necesitamos admitir múltiples formatos de datos? ¿Necesitamos hacer llamadas AJAX? (REST puede usar XMLHttpRequest) ¿La llamada es síncrona o asíncrona? ¿Es la llamada con estado o sin estado? (REST es adecuado para operaciones sin estadísticas CRUD) ¿Qué nivel de seguridad se requiere? (SOAP WS tiene mejor soporte para la seguridad) ¿Qué nivel de soporte de transacciones se requiere? (SOAP WS tiene mejor soporte para la gestión de transacciones) ¿Tenemos un ancho de banda limitado? (SOAP es más detallado) ¿Qué es lo mejor para los desarrolladores que crearán clientes para el servicio? (RESTO es más fácil de implementar, probar y mantener)

Answer 9

No tiene que elegir, los marcos modernos le permiten exponer los datos en esos formatos con un cambio mínimo. Siga los requisitos de su negocio y realice una prueba de carga de la implementación específica para comprender el rendimiento, no hay una respuesta correcta a esta pregunta sin la prueba de carga correcta de un sistema específico.