SOAP vs. REST: ¿estudios de casos pragmáticos?

Question

no estoy satisfecho con las respuestas dadas por el jabón vs REST preguntas sobre todo aquí: Performance of SOAP vs. XML-RPC or REST

porque es simplemente respuestas filosóficas generales y respuestas no pragmáticos con algunos casos de estudio.

Nadie puede dar casos precisos de cuándo el jabón sería más adecuado que el descanso, especialmente en cuanto al punto de vista del rendimiento?

Actualización: Creo que REST está ganando la guerra.

Answer 1

puede encontrar un artículo comparando REST y SOAP aquí: http://www.jopera.org/files/www2008-restws-pautasso-zimmermann-leymann.pdf

autores conclusiones parecían ser:

• Utilice los servicios de descanso para la integración táctico, ad hoc a través de Internet
• Prefiero WS - * Servicios web en escenarios de integración de aplicaciones empresariales profesionales con una vida útil más larga y requisitos avanzados de QoS

Personalmente, no me gusta la terminología como "empresa profesional" porque es informal y flexible. Sin embargo, en mi opinión, los autores hicieron algunos buenos comentarios en el artículo. Tal vez para concluir y dar algunos pensamientos propios:

• Si desea que la API sea pública, hágalo de manera RESTANTE. ¿Por qué? Es simple de usar para una aplicación cliente, por lo que hará que su servicio sea más popular. Por ejemplo, Amazon expone ambas API REST y SOAP, pero el 85% de sus usuarios han elegido la versión REST Amazon API - SOAP vs. REST

• Use SOAP y WS- * stack si va a crear (o tiene algún control del proceso de creación) tanto consumidores como productores de sus servicios y usted necesita funciones avanzadas de WS- *. Esto probablemente requerirá más recursos también porque las aplicaciones SOAP tienden a ser "más pesadas" (más funciones, pero también más sofisticación).

también teniendo en cuenta el rendimiento RESTO podría ser más rápido (mensajes son definitivamente más corto y que no es necesario analizar XML).

Espero que ayude.

En su ejemplo de cliente flash, es realmente difícil de decir sin conocer los detalles, pero si uno no necesita todas estas características de seguridad y transaccionales de WS- *, creo que la creación de la aplicación REST sería más simple y rápida.

---

Respondiendo a comentar

debería usar jabón porque estoy tan llamada "empresa profesional"

Y asumiendo por supuesto que su elección no es realmente dictado por grandes proveedores de software.

SOAP es adecuado para las grandes empresas porque fomenta un enfoque más formal. Ofrece especificaciones, que son enormes, por lo que los desarrolladores pueden necesitar tiempo para aprenderlas y tal vez incluso un poco de capacitación profesional -> para gastar los recursos de las empresas. También ofrece herramientas, y no todas ellas son de código abierto, por lo que esto también puede significar recursos adicionales. Pero si su equipo aprenderá esta forma de integrar servicios, probablemente será eficiente y el código resultante será de alta calidad.

REST en contrario es más una filosofía de desarrollo de aplicaciones. Entonces, no hay grandes especificaciones, ni herramientas especializadas. Sin gasto de recursos. Esto puede funcionar bien si tiene un pequeño equipo de buenos programadores, ya que no necesitarán tantas pautas si conocen los principios básicos. Desafortunadamente, también es más fácil hacer las cosas mal.

Otra cosa a tener en cuenta es el tamaño de las aplicaciones: cuanto más rica sea la API, más servicios se desean integrar, más difícil será hacerlo RESTful. Además, la construcción de una pequeña aplicación SOAP probablemente no sea una buena idea: el costo general de entrada y entrada es demasiado alto.

Necesita evaluar los pros y los contras para su proyecto. Es imposible dar una recomendación sin conocer todos los detalles, creo.

Y, por último, esto no tiene nada que ver con argumentos razonables, sino más con la política. Creo que la gente del nivel de gestión parece preferir WS- * stack y SOAP (tiene soporte para "grandes empresas", por lo que es más fácil para ellos justificar su elección). Por otro lado, las personas de origen académico [1] prefieren el RESTO, porque todavía hay mucha investigación que se puede realizar en el área.

[1] estoy en algún lugar entre, por lo que se puede observar tanto los comportamientos ;-)

Answer 2

El rendimiento no es el factor decisivo.

En primer lugar, debería decir que hacer una pregunta SOAP-vs-REST es un poco torpe, porque SOAP es un formato de sobre XML y REST es una arquitectura. Así que voy a hacer una pequeña suposición y supongo que realmente está considerando SOAP-vs-POX o SOAP-vs-JSON o SOAP-vs-algún otro enfoque de formato de datos.

El factor decisivo debería ser esto:
¿Necesita ahora, o necesitará en el futuro, el sobre de SOAP?

El sobre de SOAP permite cosas como encriptación, digsig, enrutamiento y comprobaciones de autorización proporcionadas por el marco, entre otras cosas. Por supuesto, puede hacer esas cosas con REST (o con mayor precisión, con plain-old-XML, o JSON, etc.) pero tiene que trabajar más usted mismo, para que eso suceda.

Si el rendimiento -cualquiera que interprete que significa- realmente es su criterio número 1, entonces probablemente debería abandonar SOAP y POX y pasar a protobufs u otra cosa optimizada para el rendimiento. Estos pueden ser más rápidos de serializar y más rápidos de transmitir.

---

Si piensa que esta respuesta es "demasiado filosófica" y que realmente quiere cifras concretas, bueno, entonces supongo que tendrá que realizar algunas pruebas. El rendimiento real variará mucho en los kits de herramientas que elija, la forma de los mensajes y los servicios de datos adicionales (como el cifrado, etc.) que utilice. Pero al final, perf no será, o no debería ser, decisivo de ninguna manera.

Si su kit de herramientas SOAP es un 20% más fácil de usar. depurar y mantener como su kit de herramientas de POX, entonces debe usar SOAP, independientemente del rendimiento. Las personas (codificadores, arquitectos, probadores) son mucho más caras que las CPU y las redes actualmente. Siempre puede comprar otras 2 cpus, o una red más grande, si es necesario, y si su diseño es correcto. Pero no puede comprar un 20% menos de tiempo de desarrollo, a cualquier costo, si su marco es difícil de usar o si aleja a su gente. A menos que esté ejecutando una red de escala geográfica, será mejor que optimice para las personas, en lugar de para la red.