¿Por qué prefieren REST sobre SOAP?

Question

Si necesito un servicio web para pasar y recibir un objeto complejo, ¿hay alguna razón por la que prefiera SOAP sobre REST? Aquí está un ejemplo de la posible mensaje SOAP:

<soap:Envelope> 
    <soap:Header> 
    <Credentials> 
     <User>Joe</User> 
     <Password>abc123</Password> 
    </Credentials> 
    </soap:Header> 
    <soap:Body> 
    <MyComplexBusinessObject> 
     <Search> 
     <First>Joe</First> 
     <Last>Smith</Last> 
     </Search> 
     ... 
     ... 
    </MyComplexBusinessObject> 
    </soap:Body> 
</soap:Envelope> 

Usando resto, sería pedir al cliente que la siguiente información XML y autenticar mediante la autenticación básica:

<MyComplexBusinessObject> 
    <Search> 
    <First>Joe</First> 
    <Last>Smith</Last> 
    </Search> 
    ... 
    ... 
</MyComplexBusinessObject> 

El mensaje SOAP es un poco más complicado, pero no por mucho. Siguen siendo ambos XML, pero SOAP viene con un WSDL y la mayoría de los entornos de programación generarán clases proxy para usted. Sin embargo, la mayoría de las personas con las que hablo me dicen que debería usar REST porque es más fácil de usar. Pero no veo cómo SOAP es más difícil de usar.

¿Echo de menos algo?

Answer 1

Su primer requisito de "pasar adelante y atrás un objeto complejo" limita su arquitectura para eliminar muchos de los beneficios de REST. SOAP está diseñado para acceder a objetos remotos, REST no. REST admite pasar tipos de medios tan simples como text/plain, que es mucho más primitivo que tratar con un objeto.

Si aún no lo ha visto, la pregunta this y sus respuestas cubren la mayoría de los problemas REST vs SOAP.

Answer 2

Una de las principales ventajas de REST es que todo lo que necesita para llamar y usar es un navegador y una pila HTTP, prácticamente todos los dispositivos y máquinas tienen eso. Entonces, si su objetivo principal es la facilidad de uso y alcance, use REST.

Uno de los principales beneficios de SOAP es que tiene una descripción de servicio WSDL y 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 y demás).

Por lo tanto, si la descubrimiento y una descripción estricta y formal del servicio son más importantes para usted, use SOAP (con la desventaja de que necesita un cliente SOAP completo para llamar a su servicio; su navegador web no será suficiente).

SOAP no es más difícil de usar, pero no es tan "penetrante" en términos de estar disponible, cualquier navegador puede llamar a un servicio REST y obtener una respuesta, pero luego necesita analizar e interpretar esa respuesta. SOAP obtiene una buena estructura de datos, pero necesita un cliente SOAP para esto.

Answer 3

Veo SOAP y REST como API ortogonales, diseñadas para hacer cosas diferentes.

SOAP es básicamente un RPC elegante, por lo que si desea enviar una solicitud de cómputo al servidor y obtener el resultado, utiliza SOAP. Si fuera local, sería una llamada de método a una instancia de objeto.

REST es una forma de crear, recuperar, actualizar y eliminar objetos remotos, no en el sentido de POO, utilizando una API uniforme. Si fuera local, sería como trabajar con un archivo.

Así que realmente responden a las diferentes necesidades. Puedes bastardear a uno para hacer el trabajo del otro, pero destruyes los significados.

Answer 4

Si desarrolla tanto el servicio como el cliente, usar SOAP es tan fácil como REST (en realidad más fácil).

Es posible que prefiera SOAP sobre RESTO si estas condiciones se encuentran:

• Toda la API del servicio es complejo, no sólo un objeto.

• El servicio se utiliza dentro de una red relativamente pequeña, y el rendimiento no es un requisito importante.

• Decide dedicar la cantidad mínima de tiempo para desarrollar tanto el servicio como la documentación de la API.