¿SOAP o REST para servicios web?

¿REST es un mejor enfoque para hacer servicios web o es SOAP? ¿O son diferentes herramientas para diferentes problemas? ¿O es una cuestión matizada, es decir, es ligeramente mejor en ciertas arenas que en otra, etc.?

Bounty-Edit:

Ahora, casi tres años después, me gustaría volver a hacer esta pregunta, ofreciendo una recompensa para alentar una respuesta en profundidad. Agradecería especialmente la información sobre esos conceptos y su relación con el universo PHP y también las modernas aplicaciones web 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 tal como 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á orientada a objetos, no define reglas de acceso. Es, podría decirse, un protocolo. Es la peor especificación de Don Box alguna vez, y eso es toda una hazaña, ya que él es el hombre que perpetró “COM”.

No hay nada útil en SOAP que no se pueda hacer con REST para el transporte, y JSON, XML o incluso texto sin formato para la representación de datos. Para la seguridad del transporte, puede usar https. Para autenticación, autenticación básica. Para las sesiones, hay cookies. La versión REST será más simple, más clara, más rápida y usará menos ancho de banda.

XML-RPC define claramente los protocolos de solicitud, respuesta y error, y hay 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 architecture, 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- * lo que lo hacen muy complejo.

Si sus consumidores son otras aplicaciones y otros servidores, hoy en día existe una gran cantidad de compatibilidad con el protocolo SOAP, y los aspectos básicos de la transferencia de datos son básicamente un clic del mouse en IDEs modernos.

Si sus consumidores son más propensos a ser RIA o clientes de 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 architecture REST, solo son mensajes a las URL. Todo funciona perfectamente, pero hay componentes clave para la expresión 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 architecture REST. Puede tener una aplicación REST sin HTTP en absoluto (mente, 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 de SOAP. Una buena lectura sobre REST se puede encontrar 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 centrarse 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 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 por URL. Esto hace que la gestión del estado sea mucho más transparente que en SOAP, donde a menudo no está claro qué estado hay en el servidor y qué hay en el cliente.

En la práctica, la mayor parte de esto desaparece, y REST normalmente solo se refiere a solicitudes HTTP simples que arrojan resultados en JSON , mientras que SOAP es una API más compleja que se comunica pasando el XML. Ambos tienen sus ventajas y desventajas, pero he descubierto que, en mi experiencia, REST suele ser la mejor opción, ya que rara vez necesitas la funcionalidad completa que obtienes de SOAP.

Rápida respuesta 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 (desarrollador definido). Además, se puede usar cualquier navegador porque el enfoque REST utiliza los verbos GET, PUT, POST y DELETE estándar. De nuevo, 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 sin estado CRUD (Crear, Leer, Actualizar y Eliminar), entonces REST es.

  • Situaciones de almacenamiento en caché. Si la información puede almacenarse en caché debido a la operación totalmente apátrida del enfoque REST, esto es perfecto. Eso cubre una gran cantidad de soluciones en los tres anteriores.

Entonces, ¿por qué siquiera consideraría SOAP? Una vez más, SOAP está bastante maduro y bien definido, y viene con una especificación completa. El enfoque REST es solo eso, un enfoque y está ampliamente abierto para el desarrollo, así que si tienes lo siguiente, SOAP es una gran solución:

  • Procesamiento e invocación asíncrona. 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 ambos lados (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 de estado conversacional, SOAP 1.2 tiene la especificación adicional en la estructura WS * para respaldar esas cosas (Seguridad, Transacciones, Coordinación, etc.). Comparativamente, el enfoque REST haría que los desarrolladores construyeran esta plomería personalizada.

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

SOAP actualmente tiene la ventaja de mejores herramientas donde generarán una gran cantidad del código repetitivo tanto para la capa de servicio como para generar clientes de 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 architecture web, permite una mejor visibilidad del protocolo, y se ha probado que escala al tamaño de la WWW. Algunos frameworks le ayudan a crear servicios REST, como Ruby on Rails, y algunos incluso le ayudan a escribir clientes, como ADO.NET Data Services. Pero en su mayor parte, falta soporte de herramientas.

SOAP es útil desde la perspectiva de las herramientas porque las herramientas consumen fácilmente el WSDL. 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 evitar el espacio de nombres en su XML de respuesta, he visto cómo los navegadores se ahogaban. Entonces, 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 más bajos que los que muestran los marcos SOAP. Y, si tiene sus patos de generación de XML alineados en el lado del servidor, puede transmitir efectivamente XML al cliente. Entonces, imagine que está leyendo filas de cursor de la 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 forma, no es necesario que recopile 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. Mire en los motores de creación de plantillas noveles o XSLT para que la transmisión funcione para REST.

Por otro lado, SOAP tiende a ser generado por los servicios generados por herramientas como un gran bloque y solo luego escrito. Esto no es una verdad absoluta, claro, hay formas de obtener las 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 procesado fácilmente por los consumidores, y los mensajes que escribo serán de mediano a pequeño (10MB o menos), y no me importaría quemar alguna CPU adicional. ciclos en el servidor, voy con SOAP. Si necesito servir a AJAX en los navegadores web, o si necesito que fluya, o si mis respuestas son gigantescas, me voy a REST.

Finalmente, existen muchos estándares geniales construidos en torno a SOAP, como WS-Security y servicios web con estado, a los que puede conectarse si usa las herramientas adecuadas. Ese tipo de cosas realmente hacen la diferencia y pueden ayudarte a satisfacer algunos requisitos peliagudos.

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

1) Implementar un servicio REST toma 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 y clientes proxy. La implementación de un servicio REST se realiza a mano y, obtenga esto, leyendo la documentación. Además, al implementar estos dos servicios, debe hacer “conjeturas” sobre lo que regresará a través del conducto ya que no existe un esquema real o documento de referencia.

2) ¿Por qué escribir un servicio REST que devuelva XML de todos modos? La única diferencia es que con REST no se conocen los tipos que representa cada elemento / atributo: usted es el único que puede implementarlo y esperar que un día una cadena no se encuentre en un campo que usted pensó que era siempre un int. SOAP define la estructura de datos utilizando WSDL, por lo que no es necesario.

3) He escuchado la queja de que con SOAP tiene la “sobrecarga” del Sobre SOAP. En este día y edad, ¿realmente tenemos que preocuparnos por un puñado de bytes?

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

5) ¿Por qué necesitamos una URL “legible” para cada recurso? Si utilizáramos una herramienta para implementar el servicio, ¿realmente nos importa la URL real?

¿Necesito continuar?

La mayoría de las aplicaciones que escribo son aplicaciones C # o Java del lado del servidor o de escritorio en WinForms o WPF. Estas aplicaciones tienden a necesitar una API de servicio más completa 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 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 una cantidad arbitraria de usos y tecnologías de clientes, iría con SOAP.

Te recomiendo que vayas con REST primero, si estás usando Java, mira 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 otras especificaciones WS- * y hay innumerables problemas de interoperabilidad si se extravía en las partes incorrectas de WSDL, XSD, SOAP, WS-Addressing, etc.

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

El otro buen enfoque para seguir con REST es que puedes reutilizar muchos códigos e infraestructuras entre una aplicación web y un front end REST. por ejemplo, renderizar HTML versus XML versus JSON de tus recursos es normalmente bastante fácil con frameworks como JAX-RS y vistas implícitas, además 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 en la web’ y hoy gime cuando se da cuenta de la pesadilla de los estándares web en los 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 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 la parte superior de la capa (VIEW, es decir, javascripts que toman 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 usar la expresividad total de XML para enviar y recibir información fuera de banda. REST, hasta donde yo sé, te limita a encabezados HTTP y códigos de resultado.

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

Respondiendo a la pregunta actualizada de 2012 (por el segundo premio) y revisando los resultados de hoy (otras respuestas).


SOAP, pros y contras

Acerca de SOAP 1.2, ventajas y desventajas cuando se compara con “REST” … Bueno, desde 2007 puede describir los servicios web REST con WSDL y utilizando el protocolo SOAP … Es decir, si trabaja un poco más, todos los estándares W3C de la stack de protocolos de servicios web puede ser REST !

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

  • SOAP-REST (= “REST-SOAP”): como lo muestra L.Mandel , WSDL2 puede describir un servicio web REST y, si suponemos que XML ejemplificado puede envolverse 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 RESTs AJAX típicos usan JSON en su lugar), algunos usan otras estructuras XML, sin los encabezados o reglas de SOAP. PD: para evitar la informalidad, podemos suponer el nivel 2 de REST en las comparaciones.

Por supuesto, para comparar más conceptualmente, compare “NON-REST-SOAP” con “NON-SOAP-REST”, ya que se aproximan diferentes modelos. Entonces, completando esta taxonomía de servicios web:

  • NON-REST-SOAP : cualquier servicio web SOAP que no puede ser REST … Es decir, “90%” de los ejemplos SOAP bien conocidos.

  • NON-REST-NI-SOAP : sí, el universo de “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 patrones : todos los niveles de la stack W3C son mutuamente compatibles. 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 yo , @DaveWoldrich (20 votos), @cynicalman (5), @Exitos (0) dije antes, en un contexto donde NECESITAN NORMAS, necesita SOAP.

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

  • Robustez : la seguridad de la estructura SOAP y los encabezados. Con la comunicación de metada (con la expresividad completa 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 en torno a la lógica de rebash y, por lo tanto, puede proporcionar más fiabilidad de extremo a extremo y garantías de servicio”, E. Terman .

Clasificando profesionales por popularidad,

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

  • Cumplimiento de Standars (25 votos): como yo , @DaveWoldrich (20 votos), @cynicalman (5), @Exitos (0) dije antes, en un contexto donde NECESITAN NORMAS, necesita SOAP.

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

CONTRAS

  • La estructura de SOAP es más compleja (más de 300 votos): todas las respuestas aquí y las fonts sobre “SOAP vs REST” manifiestan cierto desagrado con la redundancia y complejidad de SOAP. Esta es una consecuencia natural de los requisitos para la verificación formal (ver a continuación) y para la solidez (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 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.


Modelado de servicios 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 la sección “PROS”). PD: vea una típica “necesidad B2B de estándares” descrita por @saille .

  • Necesidad de herramientas (vea la sección “PROS”). PS: los estándares y la existencia de verificaciones formales (ver abajo) son cuestiones importantes para la automatización de herramientas.

  • Procesamiento paralelo en paralelo (consulte la sección “Contexto / Fundamentos” a continuación): con procesos más grandes y / o más lentos, sin importar la complejidad de SOAP, la confiabilidad y la estabilidad son las mejores inversiones.

  • Necesita más seguridad : cuando se necesita más de HTTPS y realmente necesita características adicionales para la 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 implica HTTP”, S. Seely . XML es un problema central, que ofrece estándares para XML Encryption , XML Signature y XML Canonicalization y, solo con SOAP, puede incorporar estos mecanismos en un mensaje según un estándar bien aceptado como WS-Security .

  • Necesita más flexibilidad (menos restricciones): SOAP no necesita correspondencia exacta con un URI; no restringido a HTTP; no es necesario restringir a 4 verbos. Como dice @TravisHeseman (9 votos), si desea algo “flexible para una cantidad arbitraria de tecnologías y usos del cliente”, use SOAP.
    PD: recuerde que XML es más universal / expresivo que JSON (et al).

  • Necesidad de verificaciones formales : es importante comprender que la stack W3C usa métodos formales , y REST es más informal. Su descripción de servicio WSDL ( 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 una perspectiva histórica. Para este tema, una perspectiva de 10 o 15 años …

Antes de la estandarización 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 las empresas. Los estándares de stack W3C han sido una luz, un norte para la interoperación de conjuntos de servicios web complejos.

Para tareas diarias, como implementar AJAX, SOAP es pesado … Entonces, la necesidad de enfoques simples necesita elegir un nuevo marco teórico … Y grandes “reproductores de software web”, como Google, Amazon, Yahoo, et al, eligieron la mejor alternativa, ese es el enfoque REST. Fue en este contexto que el concepto REST llegó como un “marco competitivo” y, hoy (2012), esta alternativa es un estándar de facto para los progtwigdores.

Cimientos

En un contexto de Parallel Computing, 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 grosero y embarazoso .

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.

Está 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 hace.

No pase por alto XML-RPC. Si buscas 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 una especie de renacimiento en los últimos tiempos.

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

El protocolo Simple Access Access Protocol (SOAP) estándar, un lenguaje XML que define una architecture de mensaje y formatos de mensaje, 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, mechanisam bien definido para definir servicios como WSDL + XSD, WS-Policy SOAP devolverá datos basados ​​en XML SOAP proporcionará estándares de seguridad y confiabilidad

Representational State Transfer (RESTful) servicios web. 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 plano, JSON, HTML, etc.

Para muchos tipos de clientes es más fácil consumir servicios web RESTful mientras que permite que el lado del servidor evolucione y se amplíe. Los clientes pueden optar por consumir algunos o todos los aspectos del servicio y mezclarlo con otros servicios basados ​​en la web.

  1. REST usa HTTP estándar por lo que es simple para crear clientes, 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 guardarse en caché y SOAP no puede
  5. Manejo integrado de errores donde SOAP no tiene manejo de errores
  6. REST es particularmente útil PDA y otros dispositivos móviles.

Los servicios 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 interopera con otros clientes y servidores conformes a WS. Los servicios web SOAP (como JAX-WS) son útiles para manejar el procesamiento asincrónico y la invocación.

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

REST es una architecture inventada por Roy Fielding y descrita en su disertación Architectural Styles y Design of Network-based Software Architectures . Roy es también 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 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á utilizando 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. Es probable 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 viendo el mismo problema. Me parece que en realidad REST es rápido y fácil, y es bueno para llamadas y respuestas livianas y excelente para la depuración (lo que podría ser mejor que extraer una URL en un navegador y ver la respuesta).

Sin embargo, donde REST parece caer, tiene que ver con el hecho de que no es un estándar (aunque está compuesto por estándares). La mayoría de las bibliotecas de progtwigció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, los servicios web basados ​​en REST parecen ser un enfoque más adverso 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, el negocio puede estructurar su lógica y establecer que cualquier cambio en la interfaz cambiará el wsdl. No hay espacio para manouvre. Puede validar todas las solicitudes contra ese WSDL. Sin embargo, debido a que un WSDL no describe adecuadamente 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 “respuesta” superior en este hilo parece decir que SOAP significa Protocolo de acceso orientado a objetos simples, sin embargo, al mirar wiki, la 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 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 ligero, pero no disfruto mucho trabajar con él desde la perspectiva del cliente.

Tengo curiosidad sobre lo que otros piensan.

Escucha este podcast para averiguarlo. Si quiere 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 deba utilizar REST. Si desea pasar datos estructurados entre servicios de back-end, utilice SOAP.

SOAP puede ser un verdadero problema para configurar a veces y, a menudo, es excesivo para los simples intercambios de datos entre el cliente y el servidor web. Desafortunadamente, la mayoría de los ejemplos de progtwigción simples que he visto (y aprendido de) refuerzan algo esta percepción.

Dicho esto, SOAP realmente brilla cuando comienzas a combinar múltiples servicios SOAP juntos como parte de un proceso más amplio impulsado por un flujo de trabajo de datos (software Think Enterprise). Esto es algo que muchos de los ejemplos de progtwigción SOAP no transmiten porque una operación SOAP simple para hacer algo, como buscar el precio de una acción, generalmente es demasiado complicada para lo que hace por sí misma a menos que se presente en el contexto de proporcionar una máquina API legible que detalla las funciones específicas con los formatos de datos configurados para las entradas y salidas que, a su vez, están guionadas 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 utiliza el producto final.

SOAP incorpora un enfoque orientado a servicios para servicios web, uno en el que los métodos (o verbos) son la principal forma de interactuar con el servicio. REST toma un enfoque orientado a recursos en el cual el objeto (o el sustantivo) toma el centro del escenario.

En sentido común, con PHP “universe”, el soporte de PHP para cualquier SOAP avanzado es una gran sorpresa. 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 los servicios de soap de estilo antiguo que usan SOAP Encoding (Dios sabe cómo es eso diferente) con los mensajes SOAP.

Evite todo este lío al permanecer en REST, REST no es nada grande lo hemos estado usando desde el inicio de WWW. Nos dimos cuenta solo cuando salió este documento 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 básicas 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 ¿has oído hablar del encabezado SOAP Action? Si no lo buscas en Google ahora).

Con el aumento de la adaptación JSON y HTML5 con JavaScript, la maduración de 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 etapas tempranas) junto con WADL si es necesario.

El soporte de PHP para REST y JSON es definitivamente mejor que el soporte de 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 está pensando en la adaptación Enterprise JSON definitivamente necesita venir con algo similar para JSON, como encriptación a nivel de campo, etc.

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

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

Si está buscando interoperabilidad entre diferentes sistemas e idiomas, definitivamente iré a REST. He tenido muchos problemas intentando 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:

  • REST tomó 3 segundos
  • SOAP tomó 7 segundos

para 10,000 solicitudes:

  • REST tomó 33 segundos
  • SOAP tomó 69 segundos

para 1,000,000 de solicitudes:

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

An old question but still relevant today….due to so many developers in the enterprise space still using it.

My work involves designing and developing IoT (Internet of Things) solutions. Which includes developing code for small embedded devices that communicate with the Cloud.

It is clear REST is now widely accepted and useful, and pretty much the defacto standard for the web, even Microsoft has REST support included throughout Azure. If I needed to rely on SOAP I could not do what I need to do, as is just too big, bulky and annoying for small embedded devices.

REST is simple and clean and small. Making it ideal for small embedded devices. I always scream when I am working with a web developer who sends me a WSDLs. As I will have to begin an education campaign about why this just isn’t going to work and why they are going to have to learn REST.

1.From my experience. I would say REST gives you option to access the URL which is already built. eg-> a word search in google. That URL could be used as webservice for REST. In SOAP, you can create your own web service and access it through SOAP client.

  1. REST supports text,JSON,XML format. Hence more versatile for communicating between two applications. While SOAP supports only XML format for message communication.