performance - restful - web service soap gratuito

Rendimiento de SOAP vs. XML-RPC o REST (8)

Ampliando la respuesta de "pjz".

Si obtiene muchas operaciones de SOAP basadas en INFORMACIÓN (obtenga * tipo de llamadas), actualmente no hay forma de que pueda almacenarlas en caché. Pero si implementara estas mismas operaciones con REST, existe la posibilidad de que los datos (en función del contexto de su empresa) se puedan almacenar en caché, como se mencionó anteriormente. Como SOAP utiliza POST para sus operaciones, no puede almacenar en caché la información del lado del servidor.

Los argumentos sobre la simplicidad de las soluciones que usan XML-RPC o REST son fáciles de entender y difíciles de discutir.

A menudo también he escuchado argumentos de que el aumento de la sobrecarga de SOAP puede afectar significativamente el ancho de banda utilizado y posiblemente incluso la latencia. Me gustaría ver los resultados de una prueba que cuantifica el impacto. ¿Alguien sabe una buena fuente para tal información?

El principal impacto en la velocidad de SOAP vs. REST no tiene que ver con la velocidad del cable, sino con la capacidad de caché. REST sugiere utilizar la semántica de la web en lugar de intentar pasar por encima de ella a través de XML, por lo que los servicios web RESTful generalmente están diseñados para usar correctamente los encabezados de caché, por lo que funcionan bien con la infraestructura estándar de la web como los servidores de caché e incluso los cachés de los navegadores locales. Además, usar la semántica de la web significa que cosas como ETags y la compresión automática de zip son formas bien entendidas de aumentar la eficiencia.

..y ahora dices que quieres puntos de referencia. Bueno, con la ayuda de Google, encontré a un tipo cuyas pruebas muestran que REST es 4-6 veces más rápido que SOAP y otro paper que también favorece a REST.

Hay algunos estudios que se han hecho con respecto a esto que puede encontrar informativos. Por favor mira lo siguiente:

También hay una conversación de rendimiento interesante (algo desactualizada) sobre el tema en los foros de MSDN .

En resumen, la mayoría de estas fuentes parecen estar de acuerdo en que SOAP y REST tienen aproximadamente el mismo rendimiento para los datos de propósito general. Sin embargo, algunos resultados parecen indicar que, con datos binarios, REST puede tener un rendimiento menor. Ver los enlaces en el foro que he vinculado para obtener más detalles sobre esto.

No conozco ninguna respuesta a la pregunta de evaluación comparativa, sin embargo, lo que sé sobre el formato SOAP es sí, tiene una sobrecarga, pero esa sobrecarga no aumenta por solicitud: si tiene un elemento enviado al servicio web , tiene una construcción de sobrecarga + un elemento, y si tiene 1000 elementos enviados al servicio web, tiene una construcción de más de 1000 elementos. La sobrecarga ocurre cuando la solicitud XML se formatea para la operación particular, pero cada elemento de argumento individual en la solicitud tiene el mismo formato.

Si se adhiere a ráfagas cortas y repetibles de datos (por ejemplo, 500 elementos), la velocidad debe ser aceptable.

REST como protocolo no define ninguna forma de envolvente de mensaje, mientras que SOAP tiene este estándar.

Por lo tanto, es algo simplista intentar y comparar los dos, son manzanas con naranjas.

Dicho esto, un sobre SOAP (menos los datos) es solo de unos pocos k, por lo que no debería haber ninguna diferencia notable en la velocidad siempre que esté recuperando un objeto serializado a través de SOAP y REST.

SOAP es definitivamente más lento. Las cargas útiles son significativamente más grandes, que son más lentas de ensamblar, transportar, analizar, validar y procesar.

SOAP y cualquier otro protocolo que use XML generalmente abota un poco los mensajes, esto puede o no ser un problema según el contexto.

Algo así como JSON sería más compacto y tal vez más rápido de serializar / deserializar, pero no lo use exclusivamente por ese motivo. Haga lo que sienta que tiene sentido en ese momento y cámbielo si es un problema.

Cualquier cosa que use HTTP típicamente (a menos que reutilice una conexión keepalive HTTP 1.1, que muchas implementaciones no) inicia una nueva conexión TCP para cada solicitud; esto es bastante malo, especialmente en enlaces de alta latencia. HTTPS es mucho peor. Si tiene muchas solicitudes breves de un remitente a un destinatario, piense en cómo puede tomar estos gastos generales.

Usar HTTP para cualquier tipo de RPC (ya sea SOAP u otra cosa) siempre incurrirá en esa sobrecarga. Otros protocolos RPC generalmente le permiten mantener una conexión abierta.

Supongo que la pregunta principal aquí es cómo se compara RPC con SOAP.

ambos sirven el mismo enfoque de abstracción de comunicación al tener objetos de código auxiliar con los que operas y tipos de datos primitivos / complejos que obtienes sin saber realmente cómo se maneja todo esto debajo.

Yo siempre preferiría (JSON-) RPC porque

es liviano
hay muchas implementaciones geniales para todos los lenguajes de programación
es simple de aprender / usar / crear
es rápido (especialmente con JSON)

aunque hay razones por las que debe usar SOAP, es decir, si necesita parámetros de nombres en lugar de confiar en su orden correcta

algunos más detalles que obtienes de esta question