performance - restful - Por qué HTTP/SOAP se considera "grueso"

soap vs rest diferencias

Question

He escuchado algunas opiniones de que la pila de llamadas del servicio web SOAP / HTTP es "gruesa" o "pesada", pero realmente no puedo precisar por qué. ¿Se consideraría grueso debido a la serialización / deserialización del sobre SOAP y el mensaje? ¿Es realmente una operación pesada?

¿O simplemente se considera "grueso" en comparación con una transferencia de datos en bruto / binario a través de una conexión fija?

¿O es alguna otra razón? ¿Alguien puede arrojar algo de luz sobre esto?

Answer 1

1 - Los esquemas XML, que son una parte clave de la especificación WSDL, son realmente, realmente grandes y complicados. En la práctica, las herramientas que hacen cosas como el esquema XML del mapa a las construcciones del lenguaje de programación solo terminan soportando parte de las características del esquema XML.

2 - Las especificaciones WS- *, por ejemplo, WS-Security y WS-SecureConversation, son de nuevo grandes y complicadas. Están casi diseñados para que nadie tenga menos recursos que Microsoft o IBM alguna vez podrá implementarlos por completo.

Answer 2

Creo que es principalmente que el sobre SOAP agrega una gran cantidad de sobrecarga a la construcción del mensaje, especialmente para el caso común de una simple solicitud con solo unos pocos parámetros no profundamente estructurados. Compare eso con un servicio web de estilo REST donde los parámetros simplemente se incluyen en la consulta URL.

Luego agregue a eso la complejidad de WSDL y las típicas implementaciones de la biblioteca "empresarial" ...

Answer 3

En primer lugar, depende mucho de cómo se implementen sus servicios (es decir, puede hacer mucho para reducir la carga útil con solo tener cuidado con la forma en que se realizan las firmas de sus métodos).

Dicho esto, no solo el sobre del jabón, sino el mensaje en sí mismo puede ser mucho más voluminoso en formato xml en lugar de un formato binario optimizado. Simplemente elegir la clase correcta y los nombres de los miembros puede reducirlo mucho ...

Considere los siguientes ejemplos de regresos de métodos serializados de métodos que devuelven una colección de cosas. Simplemente elegir el nombre correcto de [serialización] para clases / contenedores y miembros puede marcar una gran diferencia en la verbosidad de la solicitud / respuesta de jabón serializado si devuelve datos repetidos (por ejemplo, listas / colecciones / matrices).

Nombres breves / cortos:

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfShortIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/">
  <ShortIDName>
    <id>0</id>
    <name>foo 0</name>
  </ShortIDName>
  <ShortIDName>
    <id>1</id>
    <name>foo 1</name>
  </ShortIDName>
  <ShortIDName>
    <id>2</id>
    <name>foo 2</name>
  </ShortIDName>
  ...
</ArrayOfShortIDName>

Nombres largos:

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfThisClassHasALongClassNameIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/">
  <ThisClassHasALongClassNameIDName>
    <MyLongMemberNameObjectID>0</MyLongMemberNameObjectID>
    <MyLongMemberNameObjectName>foo 0</MyLongMemberNameObjectName>
  </ThisClassHasALongClassNameIDName>
  <ThisClassHasALongClassNameIDName>
    <MyLongMemberNameObjectID>1</MyLongMemberNameObjectID>
    <MyLongMemberNameObjectName>foo 1</MyLongMemberNameObjectName>
  </ThisClassHasALongClassNameIDName>
  <ThisClassHasALongClassNameIDName>
    <MyLongMemberNameObjectID>2</MyLongMemberNameObjectID>
    <MyLongMemberNameObjectName>foo 2</MyLongMemberNameObjectName>
  </ThisClassHasALongClassNameIDName>
  ...
</ArrayOfThisClassHasALongClassNameIDName>

Answer 4

Estoy de acuerdo con el primer afiche, pero me gustaría agregarlo. La definición gruesa y delgada es relativa. Con transportes como JSON o REST, SOAP emergente parece pesado en la superficie para ejemplos de "hello world". Ahora, como ya sabrá, SOAP es muy pesado y WS 2.0 en general es la empresa / características robustas. JSON no es seguro de la misma manera que WS 2.0. No he oído hablar de SOAP como grueso, pero muchas tuercas que no son XML ven estas especificaciones como pesadas o gruesas. Para que quede claro, no estoy hablando en favor ni en contra, ya que ambos tienen su lugar. XML más legible y legible por humanos y por lo tanto "más grueso". La última pieza es que algunas personas ven a HTTP como un protocolo de conexión persistente pesado dado las tendencias web más recientes, como AJAX, en lugar de servir en una página grande. La sobrecarga de conexión es grande dado que realmente no hay ningún beneficio.

En resumen, ninguna razón real más que alguien quiere llamar a SOAP / HTTP de espesor, es todo relativo. Menos estándares son perfectos y para todos los escenarios. Si tuviera que adivinar, algún desarrollador web inteligente piensa que está siendo tan inteligente al hablar sobre cómo son las tecnologías XML y cómo es Super JSON. Cada uno tiene un lugar.

Answer 5

La relación señal / ruido de SOAP es demasiado baja. Para una conversación simple hay demasiados gastos generales estructurales sin valor de datos; y se requiere demasiada configuración explícita (en comparación con la configuración implícita, como JSON).

No comenzó de esa manera, pero terminó siendo un póster de lo que le sucede a una buena idea cuando se involucra un comité de estándares.

Answer 6

Lo consideré "grueso" debido a la sobrecarga relativamente grande involucrada con el empaquetado y desempaquetado de un mensaje (serialización y deserialización).

Considere un servicio web con un método web llamado Add que toma dos enteros de 32 bits. La persona que llama empaqueta dos enteros y recibe un entero único en respuesta. Donde realmente solo se transmiten 96 bits de información, la adición de los paquetes SOAP probablemente agregará alrededor de 3.000 o más bits adicionales en cada dirección. Un aumento de 30x

A esto se agrega el rendimiento relativamente lento asociado con serializar y deserializar el mensaje en UTF-8 (o lo que sea) XML. Es cierto que es bastante rápido en estos días, pero ciertamente no es trivial.

Answer 7

SOAP y WSDL son estándares extremadamente complicados, que tienen muchas implementaciones que admiten diferentes subconjuntos de los estándares. SOAP no se adapta muy bien a una interfaz de función externa simple de la misma manera que lo hace XML-RPC . En su lugar, debe comprender los espacios de nombres XML, sobres, encabezados, WSDL, esquemas XML, etc. para producir mensajes SOAP correctos. Todo lo que necesita hacer para llamar a un servicio XML-RPC es definir y endpoint y llamar a un método en él. Por ejemplo, en Ruby:

require ''xmlrpc/client''

server = XMLRPC::Client.new2("http://example.com/api")
result = server.call("add", 1, 2)

Además de XML-RPC, existen otras técnicas que también pueden ser mucho más simples y livianas, como XML simple o JSON sobre HTTP (a menudo denominado REST , aunque eso implica ciertas otras consideraciones de diseño). La ventaja de algo como XML o JSON sobre HTTP es que es fácil de usar desde JavaScript o incluso una página web tonta con un envío de formulario. También se puede programar fácilmente desde la línea de comandos con herramientas como curl . Funciona con casi cualquier idioma, ya que las bibliotecas HTTP, las bibliotecas XML y las bibliotecas JSON están disponibles en casi todas partes, e incluso si un analizador JSON no está disponible, es muy fácil escribir el suyo.

Editar: Debo aclarar que me refiero a lo SOAP conceptualmente pesado, a diferencia del peso pesado en términos de cantidad de datos en bruto. Creo que la cantidad de datos en bruto es menos importante (aunque se suma rápidamente si necesita manejar muchas pequeñas solicitudes), mientras que lo conceptualmente pesado es bastante importante, porque eso significa que hay muchos más lugares donde algo puede salir mal, donde puede haber una incompatibilidad, etc.

Answer 8

SOAP está diseñado para ser lo suficientemente abstracto como para usar otros transportes además de HTTP. Eso significa, entre otras cosas, que no aprovecha ciertos aspectos de HTTP (principalmente el uso RESTful de URL y métodos, por ejemplo PUT /customers/1234 o GET /customers/1234 ).

SOAP también evita los mecanismos TCP / IP existentes por el mismo motivo: ser independiente del transporte. De nuevo, esto significa que no puede aprovechar el transporte, como la gestión de secuencias, el control de flujo, el descubrimiento de servicios (por ejemplo, accept() una conexión en un puerto conocido significa que el servicio existe), etc.

SOAP utiliza XML para toda su serialización, mientras que eso significa que los datos son "legibles universalmente" con solo un analizador XML, introduce tanto texto repetitivo que realmente necesita un analizador SOAP para funcionar de manera eficiente. Y en ese punto, usted (como consumidor de software) ha perdido el beneficio de XML de todos modos; A quién le importa cómo se ve la carga útil a través del cable si necesita libSOAP para manejarlo de todos modos.

SOAP requiere WSDL para describir interfaces. El WSDL en sí no es un problema, pero tiende a anunciarse como mucho más "dinámico" de lo que realmente es. En muchos casos, se crea un único WSDL, y el código productor / consumidor se genera automáticamente a partir de eso, y nunca cambia. En general, eso requiere muchas herramientas sin resolver realmente el problema original (cómo comunicarse entre diferentes servidores). Y dado que la mayoría de los servicios SOAP se ejecutan a través de HTTP, el problema original ya se había resuelto en su mayoría para empezar.