xml - services - ¿SOAP o REST para servicios web?

web services (28)

Actualmente, SOAP tiene la ventaja de contar con mejores herramientas, ya 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, 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 comprobado que se escala en el tamaño de la propia WWW. Algunos marcos le ayudan a construir servicios REST, 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.

¿Es REST un mejor enfoque para hacer servicios web o es SOAP? ¿O son herramientas diferentes para diferentes problemas? ¿O es un tema matizado, es decir, es un poco mejor en ciertas áreas que en otras, etc.?

Edición de recompensas:

Ahora, casi tres años después, me gustaría volver a hacer esta pregunta, ofreciendo una recompensa para alentar una respuesta en profundidad. Apreciaría especialmente la información sobre esos conceptos y su relación con el universo PHP y también con las modernas aplicaciones web de gama alta.

Construí uno de los primeros servidores SOAP, 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 cometió "COM".

No hay nada útil en SOAP que no se pueda hacer con REST para 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.

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 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 llevan llamadas a URI).

Es matizado.

Si necesita tener otra interfaz de sistemas 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 HTML funcionará.

Estoy mirando 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 proporciona estándares de seguridad y confiabilidad

Servicios web de transferencia de estado representacional (RESTful). Son servicios web de segunda generación. Los servicios web RESTful, 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 combinarlos con otros servicios basados en la web.

REST utiliza HTTP estándar, por lo que es más sencillo crear clientes y desarrollar API
REST permite muchos formatos de datos diferentes como XML, texto plano, JSON, HTML, mientras que SOAP solo permite XML.
REST tiene mejor rendimiento y escalabilidad.
Descansa y puede ser almacenado en caché y SOAP no puede
Manejo de errores incorporado donde SOAP no tiene manejo de errores
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 proporcionan estándares de seguridad y confiabilidad, entre otras cosas, e interoperan con otros clientes y servidores que cumplen con WS. Los servicios web de SOAP (como JAX-WS) son útiles para manejar la invocación y el procesamiento asíncrono.

Para el API complejo, el SOAP será más útil.

Estoy seguro de que Don Box creó SOAP como una broma: ''mira, puedes llamar 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 en que se ha convertido :-)

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

La mayoría de las aplicaciones que escribo son servidor C # o Java, o aplicaciones de escritorio en WinForms o WPF. Estas aplicaciones tienden a necesitar una API de servicio más rica que la 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 clientes SOAP para javascript; Sé que jQuery tiene uno. Por lo tanto, SOAP puede ser aprovechado desde javascript; no tan bien como un servicio REST 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.

Le recomendaría ir primero con REST: si está utilizando Java, observe JAX-RS y la implementación de 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 incorrectas de WSDL, XSD, SOAP, WS-Addressing, etc.

La mejor manera de juzgar el debate REST v SOAP es buscar en Internet: casi todos los grandes jugadores en el espacio web, google, amazon, ebay, twitter y otros, tienden a usar y prefieren las API RESTful sobre las SOAP.

El otro buen enfoque para utilizar REST es que puede reutilizar muchos códigos e infraestructuras entre una aplicación web y un extremo REST. Por ejemplo, la representación HTML frente a XML frente a JSON de sus recursos suele ser bastante sencilla con marcos como JAX-RS y vistas implícitas, además de que es fácil trabajar con recursos REST con un navegador web.

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 en los últimos tiempos.

Pregunta rápida para 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 usa los verbos estándar GET, PUT, POST y DELETE. Una vez más, recuerde que REST también puede usar el objeto XMLHttpRequest que la mayoría de los navegadores modernos soportan hoy en día, lo que agrega una bonificación adicional de AJAX.
Operaciones totalmente apátridas. Si una operación necesita continuar, 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 lo es.
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. Esto cubre muchas soluciones en los tres anteriores.

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

Procesamiento asíncrono e invocación. 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, 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, 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

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 se pueden aplicar muchos verbos diferentes a muchos nombres 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 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 parte de esto desaparece, y REST generalmente solo se refiere a solicitudes HTTP simples que arrojan resultados en JSON , mientras que SOAP es una API más compleja que se comunica al pasar XML. Ambos tienen sus ventajas y desventajas, pero en mi experiencia, REST suele ser la mejor opción, ya que rara vez, si alguna vez, necesita la funcionalidad completa que obtiene de SOAP.

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í 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, hay mucho soporte para el protocolo SOAP hoy en día, 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 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 URL. Todos perfectamente funcionales, pero hay componentes clave para el lenguaje 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 están "cómodos" con SOAP, SOAP y WSS stack 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.

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 los servicios web REST con WSDL y usar el protocolo SOAP ... Es decir, si trabaja un poco más, todos los estándares de W3C de La pila de protocolos de servicios web puede 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"): como lo mostró L.Mandel , WSDL2 puede describir un servicio web REST, y, si suponemos que un XML ejemplificado puede incluirse en SOAP, toda la implementación será "SOAP-REST" .
NON-SOAP-REST : cualquier servicio web REST que no pueda ser SOAP ... Es decir, "90%" de los ejemplos REST bien conocidos. Algunos no usan XML (por ejemplo, los REST AJAX típicos usan JSON en su lugar), otros usan otras estructuras XML, sin los encabezados o reglas SOAP. PD: para evitar la informalidad, podemos suponer martinfowler.com/articles/richardsonMaturityModel.html 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:

NON-REST-SOAP : cualquier servicio web SOAP que no pueda ser REST ... Es decir, "90%" de los ejemplos de SOAP bien conocidos.
NO REST-NEITHER-SOAP : sí, el universo del "modelado de servicios web" comprende otras cosas (por ejemplo, XML-RPC ).

Jabón en las condiciones de descanso.

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

PROS

Explicando algunos términos,

Estabilidad contractual : para todo tipo de contratos (como "acuerdos escritos"),
- Mediante el uso de estándares : todos los niveles de la pila W3C son compatibles entre sí. REST, por otro lado, no es un estándar W3C o ISO, y no tiene detalles normatizados sobre los periféricos del servicio. Entonces, como I @DaveWoldrich (20 votos), @cynicalman (5), @Exitos (0), en un contexto en el que son NECESIDADES DE ESTÁNDARES, necesitas SOAP.
- Mediante el uso de mejores prácticas : el "aspecto detallado" de las implementaciones de la pila W3C , traduce los acuerdos humanos / legales / jurídicos relevantes.
Robustez : la seguridad de la estructura y las cabeceras de jabón. Con la comunicación de metada (con la expresividad completa de XML) y la verification , tiene una "póliza de seguro" contra cualquier cambio o ruido.
SOAP tiene "fiabilidad transaccional (...) frente a fallos de comunicación. SOAP tiene más controles en torno a 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 los estándares (25 votos): como I @DaveWoldrich (20 votos), @cynicalman (5), @Exitos (0), en un contexto donde se NECESITA NORMAS, se necesita jabón.
Robustez : seguro de encabezados SOAP, @JohnSaunders (8 votos).

CONTRAS

La estructura de SOAP 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 con la redundancia y complejidad de SOAP. Esto es una consecuencia natural de los requisitos para la verificación formal (ver más abajo) y para la solidez (ver más arriba). "REST NON-SOAP" (y XML-RPC, el creador de SOAP ) puede ser más simple e informal.
La restricción "solo XML" es un obstáculo para el rendimiento cuando se utilizan servicios pequeños (~ 50 votos): consulte 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-NON-REST con comparaciones NO-SOAP-REST , y explicar cuándo es mejor usar SOAP :

Necesidad de estándares y contratos estables (ver sección "PROS"). PD: vea una típica "necesidad de normas B2B" descrita por @saille .
Necesidad de herramientas (ver sección "PROS"). PD: los 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 características adicionales para la protección, SOAP es una mejor opción ( consulte @Bell , 32 votos). "Enviar el mensaje por una ruta más complicada que la solicitud / respuesta o por un transporte que no involucra HTTP", S. Seely . XML es un problema central, ya que ofrece estándares para el cifrado XML , la firma XML y la canonización de XML , y solo con SOAP puede integrar estos mecanismos en un mensaje mediante un estándar bien aceptado como WS-Security .
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.
PD: recuerde que XML es más universal / expresivo que JSON (et al).
Necesidad de verification : es importante comprender que la pila W3C usa métodos formales , y REST es más informal. Su descripción de servicio WSDL (un lenguaje formal ) es una especificación formal de las interfaces de sus 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 de la pila W3C han sido ligeros, un norte para la interoperación de conjuntos de servicios web complejos.

Para las tareas del día a día, como para implementar AJAX, SOAP es pesado ... Por lo tanto, la necesidad de enfoques simples debe elegir un nuevo marco teórico ... Y los grandes "jugadores de software web", como Google, Amazon, Yahoo, et al, eligieron la mejor alternativa, que es el enfoque REST. Fue en este contexto que el concepto REST llegó como un "marco de competencia" y, hoy (2012), esta alternativa es un estándar de facto para los 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 "ninguna tarea": los servicios web pueden clasificarse como
Paralelismo de grano grueso y vergonzoso .

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.

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 un servicio REST de un tamaño razonable. Implementar un servicio REST toma mucho más tiempo que implementar un servicio SOAP. Y al final sale mucho más desordenado, también. Aquí están las razones por las que elegiría SOAP el 99% del tiempo:

1) La implementación de un servicio REST lleva infinitamente más tiempo 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 servicio REST se realiza de forma manual y (obtenga esto) leyendo la documentación. Además, al implementar estos dos servicios, tiene que hacer "conjeturas" sobre lo que volverá a través de la tubería, ya que no hay un esquema real o documento de referencia.

2) ¿Por qué escribir un servicio REST 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 se encuentre en un campo que pensó que siempre era un int. SOAP define la estructura de datos utilizando el WSDL, por lo que es una obviedad.

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

4) He escuchado el argumento de que con REST solo 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 usando una herramienta para implementar el servicio, ¿realmente nos importa la URL real?

¿Necesito seguir?

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 las respuestas REST tienden a ser más bajos que lo que muestran los marcos SOAP. 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. Cuando 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 en los 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 necesito algo para transmitir, o mis respuestas son gigantescas, me quedo en REST.

Finalmente, hay muchos estándares excelentes construidos 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.

Una cosa que no se ha mencionado es que un sobre de 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?)

SOAP incorpora un enfoque orientado a los servicios a los servicios web, uno en el que los métodos (o verbos) son la forma principal de interactuar con el servicio. REST adopta 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;

Uso 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).

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 soporte REST 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 los 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 no va a funcionar y por qué tendrán que aprender REST.

¡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

por 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

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 del cliente SOAP.

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

En el sentido de "PHP-universe", el soporte de PHP para cualquier SOAP avanzado es una gran tarea. Terminará usando algo como http://wso2.com/products/web-services-framework/php/ tan pronto como cruce las necesidades básicas, incluso para habilitar WS-Security o WS-RM sin soporte incorporado.

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 codificación SOAP (Dios sabe en qué se diferencia eso) en los mensajes SOAP.

Evite todo este lío al mantener REST, REST no es nada realmente grande, lo hemos estado usando desde el inicio de WWW. Solo nos dimos cuenta de que este documento http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm 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 principales de HTTP y considera a 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 del encabezado de acción de SOAP? ¡Si no lo busca 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 soporte SOAP incorporado existente que tiene.

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.

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 trabajar con él desde la perspectiva del cliente tanto como lo es.

Tengo curiosidad por lo que piensan los demás.

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

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 servicios basados en SOAP. Hasta ahora, el consumo de servicios web basados en REST parece ser un enfoque más ad hoc de escribir una interfaz para que coincida con las llamadas posibles. Hacer una solicitud de http manual y 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 establece 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 aceptar 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.

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, utilice 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 comienza a combinar múltiples servicios SOAP 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 de SOAP no pueden transmitir porque una simple operación de SOAP para hacer algo, como obtener el precio de una acción, generalmente es demasiado complicada por lo que hace por sí sola a menos que se presente en el contexto de proporcionar una máquina. API legible que detalla funciones específicas con conjuntos de formatos de datos para entradas y salidas que, a su vez, son guiadas por 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 se usa el producto final.

REST es una arquitectura inventada por Roy Fielding y descrita en su tesis 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 los servicios web REST", 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á utilizando 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.

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.