¿SOAP o REST para servicios web? [cerrado]
¿REST es un mejor enfoque para realizar servicios web o lo es SOAP? ¿O son diferentes herramientas para diferentes problemas? ¿O es una cuestión de matices, es decir, es un poco mejor en ciertos ámbitos que otro, etc.?
Agradecería especialmente información sobre esos conceptos y su relación con el universo PHP y también con las aplicaciones web modernas de alta gama.
Construí uno de los primeros servidores SOAP, incluida la generación de código y la generación WSDL, a partir de las especificaciones originales mientras se estaba desarrollando, cuando trabajaba en Hewlett-Packard. NO recomiendo usar SOAP para nada.
Las siglas “SOAP” son mentira. No es simple, no está orientado a objetos y no define reglas de acceso. Podría decirse que es un protocolo. Es la peor especificación de Don Box hasta ahora, y eso es toda una hazaña, ya que él es el hombre que perpetró "COM".
No hay nada útil en SOAP que no se pueda hacer con REST para el transporte y JSON, XML o incluso texto sin formato para la representación de datos. Para la seguridad del transporte, puede utilizar https. Para autenticación, autenticación básica. Para las sesiones, hay cookies. La versión REST será más simple, más clara, se ejecutará más rápido y utilizará menos ancho de banda.
XML-RPC define claramente los protocolos de solicitud, respuesta y error, y existen buenas bibliotecas para la mayoría de los lenguajes. Sin embargo, XML es más pesado de lo necesario para muchas tareas.
REST es una arquitectura, SOAP es un protocolo.
Ese es el primer problema.
Puede enviar sobres SOAP en una aplicación REST.
SOAP en sí es bastante básico y simple, son los estándares WSS-* los que lo hacen muy complejo.
Si sus consumidores son otras aplicaciones y otros servidores, hoy en día existe mucho soporte para el protocolo SOAP, y los conceptos básicos para mover datos son esencialmente un clic del mouse en los IDE modernos.
Si es más probable que sus consumidores sean clientes RIA o Ajax, probablemente querrá algo más simple que SOAP y más nativo para el cliente (en particular, JSON).
Los paquetes JSON enviados a través de HTTP no son necesariamente una arquitectura REST, son solo mensajes a URL. Todo perfectamente viable, pero hay componentes clave en el lenguaje REST. Sin embargo, es fácil confundirlos. Pero el hecho de que esté hablando de solicitudes HTTP no significa necesariamente que tenga una arquitectura REST. Puede tener una aplicación REST sin ningún HTTP (tenga en cuenta que esto es raro).
Por lo tanto, si tiene servidores y consumidores que se sienten "cómodos" con SOAP, la pila SOAP y WSS puede serle de gran utilidad. Si está haciendo más cosas ad hoc y desea una mejor interfaz con los navegadores web, entonces algún protocolo más ligero a través de HTTP también puede funcionar bien.
REST es un paradigma fundamentalmente diferente de SOAP. Puede encontrar una buena lectura sobre REST aquí: Cómo le expliqué REST a mi esposa .
Si no tiene tiempo para leerlo, aquí está la versión corta: REST es un cambio de paradigma al centrarse en "sustantivos" y restringir la cantidad de "verbos" que puede aplicar a esos sustantivos. Los únicos verbos permitidos son "obtener", "poner", "publicar" y "eliminar". Esto difiere de SOAP donde se pueden aplicar muchos verbos diferentes a muchos sustantivos diferentes (es decir, muchas funciones diferentes).
Para REST, los cuatro verbos se asignan a las solicitudes HTTP correspondientes, mientras que los sustantivos se identifican mediante URL. Esto hace que la gestión del estado sea mucho más transparente que en SOAP, donde a menudo no está claro qué estado hay en el servidor y cuál en el cliente.
En la práctica, sin embargo, la mayor parte de esto desaparece, y REST generalmente solo se refiere a solicitudes HTTP simples que devuelven resultados en JSON , mientras que SOAP es una API más compleja que se comunica pasando XML. Ambos tienen sus ventajas y desventajas, pero he descubierto que, según mi experiencia, REST suele ser la mejor opción porque rara vez, o nunca, necesitas la funcionalidad completa que obtienes de SOAP.
Breve información sobre la pregunta de 2012:
Las áreas para las que REST funciona muy bien son:
Ancho de banda y recursos limitados. Recuerde que la estructura de devolución está realmente en cualquier formato (definido por el desarrollador). Además, se puede utilizar cualquier navegador porque el enfoque REST utiliza los verbos estándar GET, PUT, POST y DELETE. Nuevamente, recuerde que REST también puede usar el objeto XMLHttpRequest que la mayoría de los navegadores modernos admiten hoy en día, lo que agrega una ventaja adicional de AJAX.
Operaciones totalmente sin estado. Si es necesario continuar con una operación, entonces REST no es el mejor enfoque y SOAP puede ser más adecuado. Sin embargo, si necesita operaciones CRUD (Crear, Leer, Actualizar y Eliminar) sin estado, entonces REST es la solución.
Situaciones de almacenamiento en caché. Si la información se puede almacenar en caché debido al funcionamiento totalmente sin estado del enfoque REST, esto es perfecto. Esto cubre muchas soluciones de las tres anteriores.
Entonces, ¿por qué debería considerar SOAP? Nuevamente, SOAP está bastante maduro y bien definido y viene con una especificación completa. El enfoque REST es solo eso, un enfoque y está ampliamente abierto al desarrollo, por lo que si tiene lo siguiente, SOAP es una gran solución:
Procesamiento e invocación asincrónica. Si su aplicación necesita un nivel garantizado de confiabilidad y seguridad, SOAP 1.2 ofrece estándares adicionales para garantizar este tipo de operación. Cosas como WSRM – WS-Reliable Messaging.
Contratos formales. Si ambas partes (proveedor y consumidor) tienen que ponerse de acuerdo sobre el formato de intercambio, entonces SOAP 1.2 proporciona especificaciones rígidas para este tipo de interacción.
Operaciones con estado. Si la aplicación necesita información contextual y gestión del estado conversacional, entonces SOAP 1.2 tiene la especificación adicional en la estructura WS* para soportar esas cosas (Seguridad, Transacciones, Coordinación, etc.). Comparativamente, el enfoque REST haría que los desarrolladores construyeran esta plomería personalizada.
http://www.infoq.com/articles/rest-soap-when-to-use-each
SOAP actualmente tiene la ventaja de contar con mejores herramientas que generarán una gran cantidad de código repetitivo tanto para la capa de servicio como para generar clientes desde cualquier WSDL determinado.
REST es más simple y, como resultado, puede ser más fácil de mantener, se encuentra en el corazón de la arquitectura web, permite una mejor visibilidad del protocolo y se ha demostrado que escala al tamaño de la propia WWW. Algunos marcos que existen le ayudan a crear servicios REST, como Ruby on Rails, y algunos incluso le ayudan a escribir clientes, como ADO.NET Data Services. Pero en su mayor parte, falta soporte de herramientas.
