SOAP o REST para servicios web?

Construí uno de los primeros SOAP servidores, incluida la generación de código y la generación WSDL, a partir de la especificación original a medida que se desarrollaba, cuando trabajaba en Hewlett-Packard. NO recomiendo usar SOAP para nada.

El acrónimo "SOAP" es una mentira. No es simple, no está orientado a objetos, no define reglas de acceso. Es, posiblemente, un protocolo. Es la peor especificación de Don Box, y es una gran hazaña, ya que es el hombre que perpetró "COM".

No hay nada útil en SOAP que no se puede 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 la autenticación, autenticación básica. Para las sesiones, hay galletas. La versión REST será más simple, más clara, se ejecutará más rápido y usará 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 idiomas. Sin embargo, XML es más pesado de lo que necesita para muchas tareas.

REST es una arquitectura, SOAP es un protocolo.

Ese es el primer problema.

Puede enviar SOAP sobres en una aplicación REST.

SOAP en sí mismo es en realidad bastante básico y simple, son los estándares WSS- * que lo hacen muy complejo.

Si sus consumidores son otras aplicaciones y otros servidores, existe una gran cantidad de soporte para el protocolo SOAP hoy en día, y los elementos 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 de RIA o Ajax, probablemente querrá algo más simple que SOAP y más nativo para el cliente (especialmente JSON).

Los paquetes JSON enviados a través de HTTP no son necesariamente una arquitectura REST, solo son mensajes a las URL. Todos perfectamente funcionales, pero hay componentes clave en el idioma REST. Sin embargo, es fácil confundir a los dos. Pero solo porque está hablando de solicitudes HTTP, no necesariamente significa que tenga una arquitectura REST. Puede tener una aplicación REST sin HTTP (recuerde, esto es raro).

Por lo tanto, si tiene servidores y consumidores que se sienten "cómodos" con SOAP, SOAP y la pila WSS pueden servirle bien. Si está haciendo más cosas ad hoc y desea una mejor interfaz con los navegadores web, entonces también puede funcionar un protocolo más ligero a través de HTTP.

REST es un paradigma fundamentalmente diferente de SOAP. Se puede encontrar una buena lectura de REST aquí: Cómo expliqué REST a mi esposa .

Si no tiene tiempo para leerlo, aquí está la versión corta: REST es un cambio de paradigma al enfocarse en "sustantivos", y restringir el número de "verbos" que puede aplicar a esos sustantivos. Los únicos verbos permitidos son "obtener", "poner", "publicar" y "eliminar". Esto difiere de SOAP donde muchos verbos diferentes se pueden aplicar a muchos nombres diferentes (es decir, muchas funciones diferentes).

Para REST, los cuatro verbos se asignan a las solicitudes HTTP correspondientes, mientras que los nombres se identifican mediante URL. Esto hace que la administración del estado sea mucho más transparente que en SOAP, donde a menudo no está claro qué estado está en el servidor y qué hay en el cliente.

En la práctica, aunque la mayoría de esto desaparece, y REST generalmente 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 alrededor. Ambos tienen sus ventajas y desventajas, pero en mi experiencia, REST suele ser la mejor opción porque rara vez, si alguna vez, necesita la funcionalidad completa que obtiene de SOAP.

Pregunta rápida para el 2012:

Las áreas para las que REST funciona realmente bien son:

• Ancho de banda limitado y recursos. Recuerde que la estructura de devolución está realmente en cualquier formato (definido por el desarrollador). Además, se puede usar 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 bonificación adicional de AJAX.

• Operaciones totalmente apátridas. Si una operación necesita continuar, entonces REST no es el mejor enfoque y SOAP puede ajustarse mejor. Sin embargo, si necesita operaciones CRUD (Crear, Leer, Actualizar y Eliminar) sin estado, entonces REST es eso.

• Situaciones de caché. Si la información se puede almacenar en caché debido a la operación totalmente sin estado del enfoque REST, esto es perfecto. Eso cubre muchas soluciones en los tres anteriores.

Entonces, ¿por qué incluso consideraría el jabón? Nuevamente, SOAP es bastante maduro y está bien definido y viene con una especificación completa. El enfoque REST es solo eso, un enfoque y está muy abierto para el desarrollo, por lo que si tiene lo siguiente, entonces SOAP es una excelente solución:

• Procesamiento asíncrono e invocación. Si su aplicación necesita un nivel de confiabilidad y seguridad garantizados, 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 estar de acuerdo con el formato de intercambio, SOAP 1.2 proporciona las especificaciones rígidas para este tipo de interacción.

• Operaciones con estado. Si la aplicación necesita información contextual y administración del estado conversacional, entonces SOAP 1.2 tiene la especificación adicional en la estructura WS * para admitir 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

SOAPactualmente tiene la ventaja de contar con mejores herramientas donde generarán una gran cantidad de código repetitivo tanto para la capa de servicio como para generar clientes desde cualquier WSDL determinado.

RESTOes más simple, puede ser más fácil de mantener, como resultado, se encuentra en el corazón de la arquitectura web, permite una mejor visibilidad del protocolo y se ha demostrado que se escala en el tamaño de la WWW. Algunos marcos le ayudan a construir REST servicios, como Ruby on Rails, y algunos incluso lo ayudan a escribir clientes, como ADO.NET Data Services. Pero en su mayor parte, falta soporte para herramientas.

SOAP es útil desde la perspectiva de las herramientas porque las WSDL se consumen tan fácilmente. Por lo tanto, puede obtener clientes de servicios web generados para usted en su idioma favorito.

REST juega bien con las páginas web de AJAX'y. Si mantiene sus solicitudes simples, puede hacer llamadas de servicio directamente desde su JavaScript, y eso es muy útil. Trate de evitar tener espacios de nombres en su respuesta XML, he visto que los navegadores se ahogan con ellos. Por lo tanto, xsi: type probablemente no va a funcionar para usted, no hay esquemas XML demasiado complejos.

REST tiende a tener un mejor rendimiento también. Los requisitos de CPU del código que genera REST respuestas tienden a ser más bajos que lo que SOAP frameworks exhiben. Y, si tiene sus patos de generación XML alineados en el lado del servidor, puede transmitir XML de manera efectiva al cliente. Entonces, imagina que estás leyendo filas del cursor de la base de datos. A medida que lee una fila, la formatea como un elemento XML y la escribe directamente en el consumidor del servicio. De esta manera, no tiene que recopilar todas las filas de la base de datos en la memoria antes de comenzar a escribir su salida XML; lea y escriba al mismo tiempo. Busque nuevos motores de plantillas o XSLT para que la transmisión funcione para REST.

SOAP, por otro lado, tiende a ser generado por los servicios generados por herramientas como un gran blob y solo se escribe. Esto no es una verdad absoluta, claro, hay formas de eliminar las características de transmisión de SOAP, como el uso de archivos adjuntos.

Mi proceso de toma de decisiones es el siguiente: si quiero que mi servicio sea facilitado por los consumidores, y los mensajes que escribo serán de medio a pequeño (10 MB o menos), y no me importa grabar un poco de CPU extra Ciclos en el servidor, voy con SOAP. Si necesito servir a AJAX en los navegadores web, o si necesito algo para transmitir, o mis respuestas son gigantescas, voy a REST.

Finalmente, hay muchos estándares excelentes creados alrededor de SOAP, como WS-Security y servicios web de estado, que puede conectar si está usando las herramientas adecuadas. Ese tipo de cosas realmente hacen una diferencia y pueden ayudarlo a satisfacer algunos requisitos peludos.

Sé que esta es una pregunta antigua, pero tengo que publicar mi respuesta, tal vez a alguien le resulte útil. No puedo creer la cantidad de personas que recomiendan REST sobre SOAP. Solo puedo asumir que estas personas no son desarrolladores o nunca han implementado realmente un servicio REST de un tamaño razonable. La implementación de un servicio REST lleva mucho MUCHO que la implementación de un servicio SOAP. Y al final también sale mucho más desordenado. Estas son las razones por las que elegiría SOAP 99% del tiempo:

1) La implementación de un servicio REST demora infinitamente más que la implementación de un servicio SOAP. Existen herramientas para todos los lenguajes/marcos/plataformas modernos para leer en un WSDL y generar clases y clientes proxy. La implementación de un REST servicio se realiza manualmente y, obtenga esto, leyendo la documentación. Además, al implementar estos dos servicios, debe hacer "conjeturas" sobre lo que volverá a aparecer en la tubería, ya que no hay un esquema real o un documento de referencia.

2) ¿Por qué escribir un REST servicio que devuelve XML de todos modos? La única diferencia es que con REST no conoce los tipos que representa cada elemento/atributo; está solo para implementarlo y espera que un día una cadena no aparezca en un campo que usted El pensamiento siempre fue un int. SOAP define la estructura de datos utilizando el WSDL, por lo que esto es una obviedad.

3) He escuchado la queja de que con SOAP tienes la "sobrecarga" del SOAP Sobre. En esta época, ¿realmente debemos preocuparnos por unos cuantos bytes?

4) He escuchado el argumento de que con REST simplemente puede insertar la URL en el navegador y ver los datos. Claro, si su servicio REST está usando autenticación simple o no. El servicio de Netflix, por ejemplo, utiliza OAuth, que requiere que usted firme y codifique las cosas antes de que pueda enviar su solicitud.

5) ¿Por qué necesitamos una URL "legible" para cada recurso? Si estuviéramos utilizando una herramienta para implementar el servicio, ¿realmente nos importa la URL real?

¿Necesito seguir?

La mayoría de las aplicaciones que escribo son C # o Java del lado del servidor, o aplicaciones de escritorio en WinForms o WPF. Estas aplicaciones tienden a necesitar una API de servicio más rica que REST puede proporcionar. Además, no quiero dedicar más de un par de minutos a crear mi cliente de servicio web. Las herramientas de generación de clientes de procesamiento WSDL me permiten implementar mi cliente y pasar a agregar valor empresarial.

Ahora, si estuviera escribiendo un servicio web explícitamente para algunas llamadas ajax de javascript, probablemente estaría en REST; solo por el bien de conocer la tecnología del cliente y aprovechar JSON. En mi opinión, las API de servicios web utilizadas de javascript probablemente no deberían ser muy complejas, ya que ese tipo de complejidad parece manejarse mejor en el lado del servidor.

Dicho esto, hay algunos SOAP clientes para javascript; Sé que jQuery tiene uno. Por lo tanto, SOAP puede ser aprovechado de javascript; no tan bien como un REST servicio que devuelve cadenas JSON. Entonces, si tuviera un servicio web que quisiera ser lo suficientemente complejo como para que fuera flexible para un número arbitrario de tecnologías y usos del cliente, elegiría SOAP.

Recomiendo que vayas con REST primero - si estás usando Java, observa JAX-RS y la implementación Jersey . REST es mucho más simple y fácil de interoperar en muchos idiomas.

Como han dicho otros en este hilo, el problema con SOAP es su complejidad cuando llegan las otras especificaciones WS- * y hay innumerables problemas de interoperabilidad si se desvía hacia las partes equivocadas de WSDL, XSDs, SOAP, WS-Addressing etc.

La mejor manera de juzgar el REST v SOAP debate es buscar en Internet: casi todos los grandes jugadores en el espacio web, google, Amazon, ebay, Twitter y otros. para usar y preferir las API RESTful sobre las SOAP unidades.

El otro enfoque agradable de usar REST es que puede reutilizar un montón de código e infraestructura entre una aplicación web y un REST _ front end. p.ej. Normalmente, el procesamiento de HTML versus XML versus JSON de sus recursos es bastante sencillo con marcos como JAX-RS y vistas implícitas, además de que es fácil trabajar con recursos REST con un navegador web

Estoy seguro de que Don Box creó SOAP a modo de broma: 'mírate puedes llama a los métodos RPC a través de la web' y hoy se queja cuando se da cuenta de la pesadilla de los estándares web. volverse :-)

REST es bueno, simple, implementado en todas partes (por lo tanto, es un "estándar" más que los estándares) rápido y fácil. Utilice REST.

Creo que ambos tienen su propio lugar. En mi opinión:

SOAP: Una mejor opción para la integración entre sistemas heredados/críticos y un sistema web/servicio web, en la capa de base, donde WS- * tiene sentido (seguridad, política, etc.).

RESTful : Una mejor opción para la integración entre sitios web, con API pública, en el TOP of layer (VIEW, es decir, javascripts que reciben llamadas a los URI).

Una cosa que no se ha mencionado es que un sobre SOAP puede contener encabezados y partes del cuerpo. Esto le permite utilizar la expresividad completa de XML para enviar y recibir información fuera de banda. REST, por lo que sé, lo limita a los encabezados HTTP y los códigos de resultados.

(otoh, ¿puede usar cookies con un servicio REST para enviar un tipo de "encabezado" fuera de banda?)

Respondiendo la pregunta actualizada de 2012 (por la segunda recompensa) y revisando los resultados de hoy (otras respuestas).

Jabón, pros y contras.

Acerca de SOAP 1.2, ventajas e inconvenientes cuando se compara con "REST" ... Bueno, desde 2007 puede describir REST servicios web con WSDL , y usar SOAP protocolo ... Es decir, si trabaja un poco más,todos los estándares W3C de la pila de protocolos de servicios web pueden ser REST !

Es un buen punto de partida, porque podemos imaginar un escenario en el que se evitan temporalmente todas las discusiones filosóficas y metodológicas. Podemos comparar técnicamente "SOAP-REST" con "NO SOAP-REST" en servicios similares,

• SOAP-REST (= "REST-SOAP"): as mostrado por L.Mandel , WSDL2 puede describir un REST webservice, y, si suponemos que es un XML ejemplificado puede estar envuelto en SOAP, toda la implementación será "SOAP-REST".

• NO-SOAP-REST : cualquier REST servicio web que no puede ser SOAP ... Es decir, "90%" de los conocidos REST ejemplos . Algunos no usan XML (por ejemplo, el típico [AJAX Los REST utilizan JSON), otros usan otras estructuras XML, sin los encabezados o las reglas SOAP. PD: para evitar la informalidad, podemos suponer REST nivel 2 en las comparaciones.

Por supuesto, para comparar más conceptualmente, compare "NON-REST-SOAP" con "NON-SOAP-REST", como diferentes enfoques de modelado. Así, completando esta taxonomía de servicios web:

• NO REST-SOAP : cualquier SOAP servicio web que no se puede REST ... Es decir, "90%" de los bien conocidos SOAP ejemplos .

• NO REST-NEITHER-SOAP : sí, el universo del "modelado de servicios web" comprende otras cosas (por ejemplo, XML-RPC ).

SOAP en las REST condicciones

Comparando cosas comparables: SOAP-REST con NO-SOAP-REST.

PROS

Explicando algunos términos,

• Estabilidad contractual: para todo tipo de contratos (como "acuerdos escritos"),

  • Por el uso de estándares: todos los niveles del pila W3C son compatibles entre sí. REST, por otro lado, no es un estándar W3C o ISO, y no tiene detalles normativos sobre los periféricos del servicio. , como I , @DaveWoldrich (20 votos), @cynicalman (5), @Exitos (0) dijo anteriormente, en un contexto en el que son NECESIDADES DE ESTÁNDARES, necesita SOAP.

  • Mediante el uso de mejores prácticas: el "aspecto detallado" de las implementaciones pila W3C, traduce los acuerdos humanos/legales/jurídicos relevantes.

• Robustez: la seguridad de la estructura SOAP y los encabezados. Con la comunicación de metada (con la expresividad completa de XML) y verificación tiene una "póliza de seguro" contra cualquier cambio o ruido).
  SOAP tiene "confiabilidad transaccional (...) lidiar con fallas de comunicación. SOAP tiene más controles alrededor de la lógica de reintento y, por lo tanto, puede proporcionar más confiabilidad y garantías de servicio de extremo a extremo", E. Terman .

Clasificación de los profesionales por popularidad,

• Mejores herramientas (~ 70 votos): SOAP actualmente tiene la ventaja de contar con mejores herramientas, desde 2007 y hasta 2012, porque es un estándar bien definido y ampliamente aceptado. Ver @MarkCidade (27 votos), @DaveWoldrich (20), @JoshM (13), @TravisHeseman (9).

• Cumplimiento de estándares (25 votos): as I , @DaveWoldrich (20 votos), @cynicalman (5), @Exitos (0) dicho antes, en un contexto donde se NECESITA NORMAS, necesitas jabón.

• Robustez : seguro de SOAP encabezados, @JohnSaunders (8 votos).

CONTRAS

• SOAP La estructura es más compleja (más de 300 votos): todas las respuestas aquí, y las fuentes sobre "SOAP vs REST", manifiestan cierto grado de disgusto por la redundancia y complejidad de SOAP. Esto es una consecuencia natural de los requisitos para verificación formal (ver más abajo), y para robustez (ver más arriba). "REST NON-SOAP" (y XML-RPC, el SOAP originator ) puede ser más simple e informal.

• La restricción "solo XML" es un obstáculo de rendimiento cuando se usan servicios pequeños (~ 50 votos): vea json.org/xml y esta pregunta , o esta otra) . Este punto es mostrado por @toluju (41), y otros.
  PD: como JSON no es un estándar IETF , pero podemos considerar un estándar de facto para la comunidad de software web.

Servicios de modelado con SOAP.

Ahora, podemos agregar SOAP-NO REST con NO-SOAP-REST comparaciones, y explicar cuando es mejor usar SOAP :

• Necesidad de normas y contratos estables (consulte la sección "PROS"). PD: vea un la "necesidad de estándares de B2B" descrita por @saille .

• Necesidad de herramientas (vea la sección "PROS"). PS: estándares, y la existencia de verificaciones formales (ver más abajo), son temas importantes para la automatización de las herramientas.

• Procesamiento pesado paralelo (Consulte la sección "Contexto/Fundamentos" a continuación): con procesos más grandes y/o más lentos, no importa con un poco más de complejidad de SOAP, la confiabilidad y la estabilidad son las mejores inversiones.

• Necesita más seguridad: cuando se requiere más de HTTPS, y realmente necesita funciones adicionales para su protección, SOAP es una mejor opción ( vea @Bell , 32 votos)). "Enviar el mensaje a lo largo de una ruta más complicada que la solicitud/respuesta o sobre un transporte que no involucra HTTP", S. Seely . XML es un problema central, que ofrece estándares para cifrado XML, Firma XML, y XML Canonicalization, y, solo con SOAP puede incrustar estos mecanismos en un mensaje mediante un estándar bien aceptado como WS -Seguridad.

• Necesita más flexibilidad (menos restricciones): SOAP no necesita correspondencia exacta con un URI; no es necesario restringir a HTTP; No es necesario restringir a 4 verbos. Como dice @TravisHeseman (9 votos), si desea algo "flexible para un número arbitrario de tecnologías y usos del cliente", use SOAP.
  PS: recuerda que XML es más universal/expresivo que JSON (et al).

• Necesidad de verificaciones formales: es importante entender que pila W3C usa métodos formales , y REST es más informal. Su WSDL ( una descripción del servicio lenguaje formal ) es una especificación formal de sus interfaces de servicios web, y SOAP es un protocolo robusto que acepta todas las posibles prescripciones WSDL.

CONTEXTO

Histórico

Para evaluar las tendencias es necesaria la perspectiva histórica. Para esta asignatura, una perspectiva de 10 o 15 años ...

Antes de la estandarización del W3C, hay algo de anarquía. Era difícil implementar servicios interoperables con diferentes marcos, y era más difícil, costoso y lento implementar algo interoperable entre compañías. Los estándares pila W3C han sido una luz, un norte para la interoperación de conjuntos de servicios web complejos.

Para las tareas del día a día, como implementar AJAX, SOAP es pesado ... Por lo tanto, la necesidad de enfoques simples debe elegir un nuevo marco teórico ... Y grandes "jugadores de software web" , como Google, Amazon, Yahoo y otros, eligieron la mejor alternativa, que es el enfoque REST. Fue en este contexto que REST el concepto llegó como un "marco de competencia" y, hoy (2012), esta alternativa es un estándar de facto para programadores.

Cimientos

En un contexto de Computación paralela los servicios web proporcionan subtareas paralelas; Y los protocolos, como SOAP, garantizan una buena sincronización y comunicación. No es "ninguna tarea": ​​los servicios web pueden clasificarse como
paralelismo de grano grueso y embarazoso .

A medida que la tarea aumenta, se vuelve menos significativo el "debate de complejidad" y se hace más relevante la solidez de la comunicación y la solidez de los contratos.

No pase por alto XML-RPC. Si está buscando una solución liviana, entonces hay mucho que decir sobre un protocolo que puede definirse en un par de páginas de texto e implementarse con una cantidad mínima de código. XML-RPC ha existido durante años, pero pasó de moda por un tiempo, pero el atractivo minimalista parece darle algo de un renacimiento últimamente.

Es matizado.

Si necesita tener otra interfaz de sistema con sus servicios, muchos clientes estarán más contentos con SOAP, debido a las capas de "verificación" que tiene con los contratos, WSDL y el estándar SOAP.

Para los sistemas del día a día que llaman a los sistemas, creo que SOAP es una sobrecarga innecesaria cuando una simple llamada de HTML funcionará.

Veo lo mismo, y creo que son herramientas diferentes para diferentes problemas .

El protocolo de acceso a objetos simples (SOAP) estándar, un lenguaje XML que define una arquitectura de mensajes y formatos de mensajes, es utilizado por los servicios web y contiene una descripción de las operaciones. WSDL es un lenguaje basado en XML para describir servicios web y cómo acceder a ellos. se ejecutará en SMTP, HTTP, FTP, etc. Requiere soporte de middleware, un mecanismo bien definido para definir servicios como WSDL + XSD, WS-Policy SOAP devolverá datos basados ​​en XML SOAP proporcionará estándares para seguridad y fiabilidad

Servicios web de transferencia de estado representacional (RESTful). Son servicios web de segunda generación. Los servicios web REST, se comunican a través de HTTP que los servicios basados ​​en SOAP y no requieren mensajes XML o definiciones de API de servicio WSDL. para REST no se requiere middleware, solo se necesita soporte HTTP. WADL Standard, REST puede devolver XML, texto sin formato, JSON, HTML, etc.

Es más fácil para muchos tipos de clientes consumir servicios web RESTful al tiempo que permite que el lado del servidor evolucione y se amplíe. Los clientes pueden elegir consumir algunos o todos los aspectos del servicio y combinarlo con otros servicios basados ​​en la web.

1. REST utiliza HTTP estándar, por lo que es más sencillo crear clientes y desarrollar API
2. REST permite muchos formatos de datos diferentes, como XML, texto plano, JSON, HTML, donde SOAP solo permite XML.
3. REST tiene un mejor rendimiento y escalabilidad.
4. Descansa y puede ser almacenado en caché y SOAP no puede
5. Manejo de errores incorporado donde SOAP no tiene manejo de errores
6. REST es particularmente útil PDA y otros dispositivos móviles.

Los servicios de REST son fáciles de integrar con los sitios web existentes.

SOAP tiene un conjunto de protocolos que brindan estándares de seguridad y confiabilidad, entre otras cosas, e interoperan con otros clientes y servidores que cumplen con WS. SOAP Los servicios web (como JAX-WS) son útiles para manejar el proceso asincrónico y la invocación.

Para la API compleja SOAP será más útil.

REST es una arquitectura inventada por Roy Fielding y descrita en su disertación Estilos arquitectónicos y el diseño de arquitecturas de software basadas en red . Roy también es el autor principal de HTTP - el protocolo que define la transferencia de documentos a través de la World Wide Web. HTTP es un protocolo RESTful. Cuando los desarrolladores hablan de "usar REST servicios web", probablemente sea más exacto decir "usar HTTP".

SOAP es un protocolo basado en XML que se canaliza dentro de una solicitud/respuesta HTTP, por lo que incluso si usa SOAP, también está usando REST. Existe cierto debate sobre si SOAP agrega alguna funcionalidad significativa a HTTP básico.

Antes de crear un servicio web, recomendaría estudiar HTTP. Lo más probable es que sus requisitos puedan implementarse con la funcionalidad ya definida en la especificación, por lo que no se necesitarán otros protocolos.

Estoy mirando el mismo problema. Me parece que en realidad REST es rápido y fácil y bueno para llamadas y respuestas livianas y excelente para la depuración (lo que podría ser mejor que enviar una URL a un navegador y ver la respuesta).

Sin embargo, donde REST parece caerse tiene que ver con el hecho de que no es un estándar (aunque está compuesto de estándares). La mayoría de las bibliotecas de programación tienen una forma de inspeccionar un WSDL para generar automáticamente el código de cliente necesario para consumir un SOAP servicios basados ​​en. Hasta ahora, el consumo de servicios web basados ​​en REST parece un enfoque más ad hoc de escribir una interfaz para que coincida con las llamadas posibles. Hacer una solicitud de http manual luego analizar la respuesta. Esto en sí mismo puede ser peligroso.

La belleza de SOAP es que una vez que se emite un WSDL, las empresas pueden estructurar su aorund lógico que establezca el contrato, cualquier cambio en la interfaz cambiará el wsdl. No hay espacio para la maniobra. Puede validar todas las solicitudes contra ese WSDL. Sin embargo, debido a que un WSDL no describe correctamente un servicio REST, entonces no tiene una forma definida de acordar la interfaz para la comunicación.

Desde una perspectiva empresarial, esto parece dejar la comunicación abierta a la interpretación y al cambio, lo que parece una mala idea.

La parte superior de 'Respuesta' en este hilo parece decir que SOAP significa Protocolo de acceso simple orientado a objetos, sin embargo, al mirar wiki, O significa Objeto no orientado a Objetos. Son cosas diferentes.

Sé que esta publicación es muy antigua pero pensé que debería responder con mis propios hallazgos.

Es una buena pregunta ... No quiero desviarte, así que estoy abierto a las respuestas de otras personas tanto como tú. Para mí, realmente se reduce al costo de los gastos generales y al uso de la API. Prefiero consumir servicios web al crear software de cliente, sin embargo, no me gusta el peso de SOAP. El DESCANSO, creo, es más liviano, pero no disfruto mucho trabajando con él desde la perspectiva del cliente.

Tengo curiosidad por lo que piensan los demás.

Escuche este podcast para averiguarlo. Si desea saber la respuesta sin escuchar, entonces OK, es REST. Pero realmente recomiendo escuchar.

Mi regla general es que si desea que un cliente web del navegador se conecte directamente a un servicio, probablemente debería usar REST. Si desea pasar datos estructurados entre servicios de back-end, use SOAP.

SOAP puede ser un verdadero problema de configurar a veces y es a menudo excesivo para el simple intercambio de datos de servidor y cliente web. Desafortunadamente, los ejemplos de programación más simples que he visto (y de los que he aprendido) refuerzan algo esta percepción.

Dicho esto, SOAP realmente brilla cuando empiezas a combinar múltiples SOAP servicios como parte de un proceso más grande impulsado por un flujo de trabajo de datos (piense en el software empresarial). Esto es algo que muchos de los ejemplos de programación SOAP no pueden transmitir porque una simple SOAP operación para hacer algo, como buscar el precio de una acción, generalmente es demasiado complicada por lo que hace. a sí mismo, a menos que se presente en el contexto de proporcionar una API legible por máquina que detalle funciones específicas con formatos de datos establecidos para entradas y salidas que, a su vez, están programados mediante un proceso más amplio.

Esto es triste, en cierto modo, ya que realmente le da a SOAP una mala reputación porque es difícil mostrar las ventajas de SOAP sin presentarla en el contexto completo de cómo el producto final se utiliza.

En el sentido de "PHP-universe" PHP soporte para cualquier SOAP avanzado apesta. Terminarás usando algo como http://wso2.com/products/web-services-framework/php/ tan pronto como cruces las necesidades básicas, incluso para habilitar WS-Security o WS-RM no incorporado apoyo.

Creación de sobres SOAP Me siento muy desordenado en PHP, la forma en que crea espacios de nombres, xsd: nil, xsd: anytype y servicios de jabón de estilo antiguo que usan SOAP Codificación (Dios sabe en qué es diferente) con SOAP mensajes.

Evita todo este lío al mantener REST, REST no es nada realmente grande, lo hemos estado usando desde el inicio de WWW. Nos dimos cuenta solo cuando salió este http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm paper, que muestra cómo podemos usar las capacidades HTTP para implementar los Servicios RESTFul. HTTP es inherentemente REST, lo que no significa que usar HTTP hace que sus servicios sean RESTFul.

SOAP descuida las capacidades centrales de HTTP y considera HTTP solo como un protocolo de transporte, por lo tanto, en teoría, es un protocolo de transporte independiente (en la práctica no es el caso. ¿Ha oído hablar de SOAP Encabezado de acción? Si no lo busca en Google ahora !).

Con el aumento de la adaptación de JSON y HTML5 con la maduración de javascript REST con JSON se ha convertido en la forma más común de tratar con los servicios. El esquema JSON también se ha definido, se puede usar para soluciones de nivel empresarial (aún en las primeras etapas) junto con WADL si es necesario.

El soporte de PHP para REST y JSON es definitivamente mejor que el existente SOAP tiene soporte.

Agregando algunas palabras BUZZ más aquí SOA, WOA, ROA

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

por cierto, me encanta SOAP especialmente para la especificación WS-Security, esta es una buena especificación y si alguien que piensa en la adaptación Enterprise JSON definitivamente debe venir con algo similar para JSON, como el cifrado a nivel de campo, etc. .

SOAPrepresenta un enfoque orientado a los servicios a los servicios web, en el que los métodos (o verbos) son la forma principal en que interactúa con el servicio.RESTOadopta un enfoque orientado a los recursos en el que el objeto (o el sustantivo) ocupa un lugar central.

Un punto rápido - protocolo de transmisión y orquestación;

Utilizo SOAP sobre TCP por razones de velocidad, confiabilidad y seguridad, incluidos los servicios orquestados de máquina a máquina (ESB) y servicios externos. Cambie la definición del servicio, la orquestación genera un error del cambio de WSDL y es inmediatamente obvio y se puede reconstruir/implementar.

No estoy seguro de que puedas hacer lo mismo con REST - ¡Espero ser corregido o por supuesto! Con REST, cambie la definición del servicio; nada lo sabe hasta que devuelve 400 (o lo que sea).

Si está buscando interoperabilidad entre diferentes sistemas e idiomas, definitivamente me gustaría ir a REST. He tenido muchos problemas al intentar que SOAP funcione entre .NET y Java, por ejemplo.

¡Creo un punto de referencia para encontrar cuál de ellos es más rápido! Veo este resultado:

para 1000 peticiones:

• REST tomó 3 segundos
• Jabón tomó 7 segundos

para 10,000 solicitudes:

• REST tomó 33 segundos
• Jabón tomó 69 segundos

para 1,000,000 peticiones:

• REST tomó 62 segundos
• SOAP tomó 114 segundos

Una pregunta antigua pero aún relevante hoy en día ... debido a la cantidad de desarrolladores en el espacio empresarial que aún la usan.

Mi trabajo consiste en diseñar y desarrollar soluciones de IoT (Internet of Things). Lo que incluye el desarrollo de código para pequeños dispositivos embebidos que se comunican con la nube.

Está claro que REST ahora es ampliamente aceptado y útil, y más o menos el estándar de facto para la web, incluso Microsoft tiene REST soporte incluido en todo Azure. Si tuviera que confiar en SOAP no podría hacer lo que tengo que hacer, ya que es demasiado grande, voluminoso y molesto para dispositivos incrustados pequeños.

RESTO es simple y limpio y pequeño. Por lo que es ideal para dispositivos incrustados pequeños. Siempre grito cuando trabajo con un desarrollador web que me envía un WSDL. Como tendré que comenzar una campaña educativa sobre por qué esto simplemente no va a funcionar y por qué tendrán que aprender REST.

1. De mi experiencia. Yo diría que REST te da la opción de acceder a la URL que ya está construida. eg-> una búsqueda de palabras en google. Esa URL podría ser utilizada como servicio web para REST. En SOAP, puede crear su propio servicio web y acceder a él a través de SOAP cliente.

2. REST soporta texto, JSON, formato XML. De ahí que sea más versátil para la comunicación entre dos aplicaciones. Si bien SOAP solo admite el formato XML para la comunicación de mensajes.