¿Es REST un mejor enfoque para hacer servicios web o SOAP? ¿O son diferentes herramientas para diferentes problemas? ¿O es un problema matizado, es decir, uno es un poco mejor en ciertos ámbitos que otro, etc.?

Agradecería especialmente la información sobre esos conceptos y su relación con el universo PHP y también con las aplicaciones web modernas de alta gama.

Creé 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 mientras 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 toda una hazaña, ya que 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 usar https. Para la 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 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 sobres SOAP en una aplicación REST.

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

Si sus consumidores son otras aplicaciones y otros servidores, hoy en día hay mucho soporte para el protocolo SOAP, y lo básico para mover datos es esencialmente un clic del mouse en los IDE modernos.

Si es más probable que sus consumidores sean clientes de RIA o Ajax, es probable que desee 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, son solo mensajes a URL. Todo perfectamente viable, pero hay componentes clave para el idioma REST. Sin embargo, es fácil confundir a los dos. 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 HTTP en absoluto (tenga en cuenta que esto es raro).

Entonces, 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 un protocolo más ligero sobre HTTP también puede funcionar bien.

REST es un paradigma fundamentalmente diferente del SOAP. Una buena lectura sobre REST se puede encontrar 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 enfocarse en "sustantivos" y restringir el número de "verbos" que puede aplicar a esos sustantivos. Los únicos verbos permitidos son "get", "put", "post" y "delete". 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 nombres se identifican por URL. Esto hace que la administración de estado sea mucho más transparente que en SOAP, donde a menudo no está claro qué estado está en el servidor y qué está en el cliente.

En la práctica, aunque la mayor parte de esto se cae, 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 al pasar XML. Ambos tienen sus ventajas y desventajas, pero he descubierto que, en mi experiencia, REST suele ser la mejor opción porque rara vez se necesita la funcionalidad completa que se obtiene de SOAP.

Detalle rápido para la pregunta de 2012:

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

• Ancho de banda y recursos limitados. Recuerde que la estructura de retorno está realmente en cualquier formato (definido por el desarrollador). Además, se puede usar cualquier navegador porque el enfoque REST usa los verbos GET, PUT, POST y DELETE estándar. 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 encajar mejor. Sin embargo, si necesita operaciones CRUD sin estado (Crear, Leer, Actualizar y Eliminar), entonces REST lo es.

• Situaciones de almacenamiento en 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é debería considerar SOAP? 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 - Mensajería confiable de WS.

• 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 gestió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 construyan esta tubería personalizada.

http://www.infoq.com/articles/rest-soap-when-to-use-each

SOAP actualmente tiene la ventaja de mejores herramientas donde generarán una gran cantidad del código repetitivo tanto para la capa de servicio como para generar clientes desde cualquier WSDL dado.

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 escala al tamaño de la propia WWW. Algunos marcos te ayudan a construir servicios REST, como Ruby on Rails, y algunos incluso te ayudan a escribir clientes, como ADO.NET Data Services. Pero en su mayor parte, falta el soporte de herramientas.

SOAP es útil desde una perspectiva de herramientas porque el WSDL es muy fácil de consumir por las herramientas. Por lo tanto, puede obtener clientes de servicios web generados para usted en su idioma favorito.

REST funciona bien con las páginas web de AJAX. Si mantiene sus solicitudes simples, puede hacer llamadas de servicio directamente desde su JavaScript, y eso es muy útil. Intente mantenerse alejado de tener espacios de nombres en su XML de respuesta, he visto a los navegadores ahogarse con ellos. Por lo tanto, xsi: type probablemente no funcione 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 respuestas REST tienden a ser inferiores a los que exhiben 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 de cursor de base de datos. A medida que lee una fila, la formatea como un elemento XML y la escribe directamente al 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: lee y escribe 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 luego escrito. Esto no es una verdad absoluta, recuerda, hay formas de obtener características de transmisión de SOAP, como mediante 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 tamaño medio a pequeño (10 MB o menos), y no me importa quemar una CPU adicional ciclos en el servidor, voy con SOAP. Si necesito servir a AJAX en navegadores web, o necesito la transmisión, o mis respuestas son gigantescas, voy a REST.

Finalmente, hay muchos estándares excelentes construidos alrededor de SOAP, como WS-Security y obtener servicios web con estado, a los que puede conectarse si está utilizando las herramientas adecuadas. Ese tipo de cosas realmente marca la diferencia y puede ayudarlo a satisfacer algunos requisitos difíciles.

Sé que esta es una vieja pregunta, pero tengo que publicar mi respuesta, tal vez alguien lo encuentre útil. No puedo creer cuántas personas recomiendan REST sobre SOAP. Solo puedo suponer que estas personas no son desarrolladores o que nunca han implementado un servicio REST de un tamaño razonable. Implementar un servicio REST lleva MUCHO más tiempo que implementar un servicio SOAP. Y al final sale mucho más desordenado también. Estas son las razones por las que elegiría SOAP el 99% del tiempo:

1) Implementar un servicio REST lleva infinitamente más tiempo que implementar un servicio SOAP. Existen herramientas para todos los lenguajes / frameworks / plataformas modernos para leer en un WSDL y generar clases proxy y clientes. La implementación de un servicio REST se realiza a mano y, consiga esto, leyendo la documentación. Además, al implementar estos dos servicios, debe hacer "conjeturas" sobre lo que volverá a aparecer a través de la tubería ya que no existe 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 algún día no se encuentre una cadena en un campo que pensó que siempre era un int. SOAP define la estructura de datos utilizando el WSDL, por lo que es obvio.

3) He escuchado la queja de que con SOAP tienes la "sobrecarga" del SOAP Envelope. En la actualidad, ¿realmente debemos preocuparnos por un puñado de bytes?

4) He escuchado el argumento de que con REST puede simplemente abrir la URL en el navegador y ver los datos. Claro, si su servicio REST está utilizando autenticación simple o no. El servicio de Netflix, por ejemplo, usa OAuth, que requiere que firmes y codifiques cosas antes de que puedas enviar tu 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?

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 la que REST puede proporcionar. Además, no quiero pasar más de un par de minutos creando 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 comercial.

Ahora, si estuviera escribiendo un servicio web explícitamente para algunas llamadas javascript ajax, probablemente estaría en REST; solo por el hecho de conocer la tecnología del cliente y aprovechar JSON. En mi opinión, las API de servicios web utilizadas desde 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 se puede aprovechar de javascript; simplemente 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 de clientes, optaría por SOAP.

Recomiendo ir primero con REST; si está utilizando Java, mire JAX-RS y la implementación de Jersey . REST es mucho más simple y fácil de interoperar en muchos idiomas.

Como otros han dicho en este hilo, el problema con SOAP es su complejidad cuando entran las otras especificaciones WS- * y hay innumerables problemas de interoperabilidad si te desvías a las partes incorrectas de WSDL, XSD, SOAP, WS-Addressing, etc.

La mejor manera de juzgar el debate REST v SOAP es mirar 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 a las SOAP.

El otro buen enfoque para utilizar REST es que puede reutilizar gran cantidad de código e infraestructura entre una aplicación web y un front-end REST. Por ejemplo, renderizar HTML versus XML versus JSON de sus recursos normalmente es bastante fácil con marcos como JAX-RS y vistas implícitas, además de que es fácil trabajar con recursos RESTful usando un navegador web

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 gime cuando se da cuenta de la pesadilla inflada de los estándares web en la que se ha convertido :-)

REST es bueno, simple, implementado en todas partes (por lo que es más un "estándar" que los estándares) rápido y fácil. Use 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 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 la parte SUPERIOR de la capa (VIEW, es decir, javascripts que reciben llamadas a 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, hasta donde yo sé, lo limita a encabezados HTTP y códigos de resultados.

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

No pase por alto XML-RPC. Si solo busca una solución liviana, hay mucho que decir sobre un protocolo que se puede definir en un par de páginas de texto e implementar en 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 estar dándole un resurgimiento en los últimos tiempos.

Respondiendo a 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 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 todas las discusiones filosóficas y metodológicas se evitan temporalmente. Podemos comparar técnicamente "DESCANSO DE JABÓN" con "DESCANSO DE NO JABÓN" en servicios similares,

• SOAP-REST (= "REST-SOAP"): como lo demostró L.Mandel , WSDL2 puede describir un servicio web REST y, si suponemos que el XML ejemplificado se puede envolver en SOAP, toda la implementación será "SOAP-REST" .

• NO-SOAP-REST : cualquier servicio web REST que no puede 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), algunos usan otras estructuras XML, sin los encabezados o reglas SOAP. PD: para evitar la informalidad, podemos suponer REST nivel 2 en las comparaciones.

Por supuesto, para comparar más conceptualmente, compare "NO-REST-SOAP" con "NON-SOAP-REST", a medida que se acercan diferentes modelos. Entonces, completando esta taxonomía de servicios web:

• NO-REST-SOAP : cualquier servicio web SOAP que no puede ser REST ... Es decir, "90%" de los ejemplos 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 REST

Comparando cosas comparables: SOAP-REST con NON-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 mutuamente compatibles. REST, por otro lado, no es un estándar W3C o ISO, y no tiene detalles normalizados sobre los periféricos del servicio. Entonces, como dije yo , @DaveWoldrich (20 votos), @cynicalman (5), @Exitos (0) dije antes, en un contexto donde NECESITAS NORMAS, necesitas JABÓN.

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

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

Ordenando profesionales por popularidad,

• Mejores herramientas (~ 70 votos): SOAP actualmente tiene la ventaja de 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 dije antes , @DaveWoldrich (20 votos), @cynicalman (5), @Exitos (0), en un contexto donde NECESITAS NORMAS, necesitas 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. Esta es una consecuencia natural de los requisitos para la verificación formal (ver más abajo) y para la robustez (ver arriba). "REST NON-SOAP" (y XML-RPC, el creador de SOAP ) puede ser más simple e informal.

• La restricción de "solo XML" es un obstáculo de rendimiento cuando se utilizan servicios pequeños (~ 50 votos): consulte json.org/xml y esta pregunta , o esta otra . Este punto lo muestran @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 NON-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 B2B de estándares" descrita por @saille .

• Necesidad de herramientas (ver la sección "PROS"). PD: los estándares y la existencia de verificaciones formales (ver más abajo) son cuestiones importantes para la automatización de herramientas.

• Procesamiento pesado paralelo (consulte la sección "Contexto / Fundamentos" a continuación): con procesos más grandes y / o más lentos, sin importar un poco más de complejidad de SOAP, la fiabilidad 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 protección, SOAP es una mejor opción ( consulte @Bell , 32 votos). "Enviar el mensaje a lo largo de una ruta más complicada que la solicitud / respuesta o por un transporte que no involucra HTTP", S. Seely . XML es un tema central, que ofrece estándares para cifrado XML , firma XML y canonización 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 nedd 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 de clientes", use SOAP.
  PD: recuerde que XML es más universal / expresivo que JSON (et al).

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

CONTEXTO

Histórico

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

Antes de la estandarización del W3C, hay algo de anarquía. Fue difícil implementar servicios interoperables con diferentes marcos y más difícil, costoso y lento implementar algo interoperable entre empresas. 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 diarias, como implementar AJAX, SOAP es pesado ... Entonces, la necesidad de enfoques simples necesita elegir un nuevo marco teórico ... Y grandes "jugadores de software web", como Google, Amazon, Yahoo, et al, eligieron la mejor alternativa, ese es el enfoque REST. En este contexto, el concepto REST llegó como un "marco competitivo" 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 protocolos, como SOAP, aseguran una buena sincronización y comunicación. No es "ninguna tarea": ​​los servicios web se pueden clasificar como
paralelismo vergonzoso y vergonzoso .

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

Es matizado.

Si necesita que otros sistemas interactúen 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 lo hará.

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

El estándar de Protocolo simple de acceso a objetos (SOAP), un lenguaje XML que define una arquitectura de mensajes y formatos de mensajes, es utilizado por los servicios web que contienen 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, 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 representativo (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 ni definiciones de API de servicio WSDL. para REST no se requiere middleware, solo se necesita soporte HTTP. WADL Standard, REST puede devolver XML, texto plano, 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 escale. Los clientes pueden optar por 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 simple crear clientes, desarrollar API
2. REST permite muchos formatos de datos diferentes como XML, texto plano, JSON, HTML, mientras que SOAP solo permite XML.
3. REST tiene mejor rendimiento y escalabilidad.
4. Descansar y se puede almacenar en caché y SOAP no
5. Manejo de errores incorporado donde SOAP no tiene manejo de errores
6. REST es particularmente útil PDA y otros dispositivos móviles.

REST es que los servicios son fáciles de integrar con 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 conformes con WS. Los servicios web SOAP (como JAX-WS) son útiles para manejar el procesamiento asíncrono y la invocación.

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

REST es una arquitectura inventada por Roy Fielding y descrita en su disertación Architectural Styles y Design of Network-based Software Architectures . 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 hace un túnel 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 al HTTP básico.

Antes de crear un servicio web, recomendaría estudiar HTTP. Lo más probable es que sus requisitos se puedan implementar 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 depurar (lo que podría ser mejor que bombear una URL en un navegador y ver la respuesta).

Sin embargo, cuando REST parece caer, 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 un enfoque más ad hoc de escribir una interfaz para que coincida con las llamadas que son posibles. Hacer una solicitud 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 lógica que establece que cualquier cambio en la interfaz cambiará el wsdl. No hay lugar para la obra. 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 comercial, esto parece dejar la comunicación abierta a interpretación y cambio, lo que parece una mala idea.

La 'Respuesta' superior en este hilo parece decir que SOAP significa Protocolo simple de acceso orientado a objetos, sin embargo, mirar wiki significa O no Objeto 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 cuál es el uso de la API. Prefiero consumir servicios web al crear software de cliente, sin embargo, no me gusta el peso de SOAP. REST, creo, es más liviano, pero no disfruto tanto trabajar desde la perspectiva del cliente.

Tengo curiosidad por lo que piensan los demás.

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

Mi regla general es que si desea que un cliente web de navegador se conecte directamente a un servicio, entonces probablemente debería usar REST. Si desea pasar datos estructurados entre servicios de fondo, utilice SOAP.

SOAP puede ser una verdadera molestia para configurar a veces y a menudo es excesivo para intercambios de datos simples de clientes y servidores web. Desafortunadamente, la mayoría de los ejemplos de programación simples que he visto (y aprendí) refuerzan de alguna manera esta percepción.

Dicho esto, SOAP realmente brilla cuando comienzas a combinar múltiples servicios SOAP juntos 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 operación SOAP para hacer algo, como obtener el precio de una acción, generalmente es demasiado complicada para lo que hace por sí mismo a menos que se presente en el contexto de proporcionar una máquina API legible que detalla funciones específicas con formatos de datos establecidos para entradas y salidas que, a su vez, está guionizada 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 presentarlo en el contexto completo de cómo se usa el producto final.

SOAP incorpora un enfoque orientado 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.

En el sentido de "PHP-universe", el soporte de PHP para cualquier SOAP avanzado es muy malo. 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.

Creo que la creación de sobres SOAP es muy desordenada en PHP, la forma en que crea espacios de nombres, xsd: nil, xsd: anytype y servicios de jabón de estilo antiguo que usan la codificación SOAP (Dios sabe qué tan diferente) con los mensajes SOAP.

Evite todo este desorden apegándose a REST, REST no es nada realmente grande lo hemos estado usando desde el comienzo de WWW. Solo nos dimos cuenta cuando apareció este http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm que muestra cómo podemos usar las capacidades HTTP para implementar los servicios RESTFul. HTTP es inherentemente REST, eso no significa que solo usar HTTP haga que sus servicios sean RESTFul.

SOAP descuida las capacidades centrales de HTTP y considera HTTP solo como un protocolo de transporte, por lo tanto, es un protocolo de transporte independiente en teoría (en la práctica no es el caso, ¿ha oído hablar del encabezado SOAP Action? ¡Si no es Google ahora!).

Con el aumento de la adaptación 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 y se puede usar para soluciones de nivel empresarial (aún en las primeras etapas) junto con WADL si es necesario.

El soporte 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 tiene que venir con algo similar para JSON, como el cifrado de nivel de campo, etc.

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 puede reconstruirse / implementarse.

No estoy seguro de que pueda hacer lo mismo con REST: ¡espero que me corrijan o, por supuesto! Con REST, cambie la definición del servicio; nada lo sabe hasta que devuelva 400 (o lo que sea).

Si está buscando interoperabilidad entre diferentes sistemas e idiomas, definitivamente elegirí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áles de ellos son más rápidos! veo este resultado:

para 1000 solicitudes:

• RESTO tomó 3 segundos
• El jabón tomó 7 segundos

para 10,000 solicitudes:

• REST tomó 33 segundos
• El jabón tomó 69 segundos

para 1,000,000 de solicitudes:

• REST tomó 62 segundos
• El jabón tomó 114 segundos

Una vieja pregunta pero aún relevante hoy en día ... debido a que muchos desarrolladores en el espacio empresarial todavía la usan.

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

Está claro que REST ahora es ampliamente aceptado y útil, y prácticamente el estándar de facto para la web, incluso Microsoft tiene soporte REST incluido en 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 pequeños dispositivos integrados.

REST es simple, limpio y pequeño. Haciéndolo ideal para pequeños dispositivos integrados. Siempre grito cuando estoy trabajando con un desarrollador web que me envía un WSDL. Como tendré que comenzar una campaña de educación 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. por ejemplo, una búsqueda de palabras en google. Esa URL podría usarse como servicio web para REST. En SOAP, puede crear su propio servicio web y acceder a él a través del cliente SOAP.

2. REST admite texto, JSON, formato XML. Por lo tanto, es más versátil para comunicarse entre dos aplicaciones. Mientras que SOAP solo admite el formato XML para la comunicación de mensajes.