¿Alguien puede explicar qué es REST y qué es SOAP en inglés simple? ¿Y cómo funcionan los servicios web?

Explicación simple sobre SOAP y REST

SOAP - "Protocolo simple de acceso a objetos"

SOAP es un método para transferir mensajes, o pequeñas cantidades de información, a través de Internet. Los mensajes SOAP están formateados en XML y generalmente se envían utilizando HTTP (protocolo de transferencia de hipertexto).

Descanso: transferencia de estado representativo

El descanso es una forma simple de enviar y recibir datos entre el cliente y el servidor y no tiene muchos estándares definidos. Puede enviar y recibir datos como JSON, XML o incluso texto sin formato. Tiene un peso ligero en comparación con SOAP.

Ambos métodos son utilizados por muchos de los grandes jugadores. Es una cuestión de preferencia. Mi preferencia es REST porque es más fácil de usar y entender.

Protocolo simple de acceso a objetos (SOAP):

• SOAP crea un protocolo XML sobre HTTP o, a veces, TCP / IP.
• SOAP describe funciones y tipos de datos.
• SOAP es un sucesor de XML-RPC y es muy similar, pero describe una forma estándar de comunicación.
• Varios lenguajes de programación tienen soporte nativo para SOAP, por lo general, le proporciona una URL de servicio web y puede llamar a sus funciones de servicio web sin la necesidad de un código específico.
• Los datos binarios que se envían deben codificarse primero en un formato como codificado en base64.
• Tiene varios protocolos y tecnologías relacionadas: WSDL, XSD, SOAP, WS-Addressing

Transferencia de estado representativo (REST):

• REST no necesita estar sobre HTTP, pero la mayoría de mis puntos a continuación tendrán un sesgo HTTP.
• REST es muy ligero, dice espera un minuto, no necesitamos toda esta complejidad que SOAP creó.
• Por lo general, utiliza métodos HTTP normales en lugar de un gran formato XML que describe todo. Por ejemplo, para obtener un recurso, usa HTTP GET, para poner un recurso en el servidor, usa HTTP PUT. Para eliminar un recurso en el servidor, utiliza HTTP DELETE.
• REST es muy simple ya que utiliza métodos HTTP GET, POST y PUT para actualizar recursos en el servidor.
• REST generalmente se usa mejor con la Arquitectura Orientada a Recursos (ROA). En este modo de pensar, todo es un recurso, y usted operaría con estos recursos.
• Siempre que su lenguaje de programación tenga una biblioteca HTTP, y la mayoría lo haga, puede consumir un protocolo REST HTTP muy fácilmente.
• Los datos binarios o los recursos binarios simplemente se pueden entregar a pedido.

Hay un sinfín de debates sobre REST vs SOAP en google .

Mi favorito es este . Actualización del 27 de noviembre de 2013: el sitio de Paul Prescod parece haberse desconectado y este artículo ya no está disponible, aunque se pueden encontrar copias en Wayback Machine o en formato PDF en CiteSeerX .

DESCANSO

Entiendo que la idea principal de REST es extremadamente simple. Hemos utilizado navegadores web durante años y hemos visto lo fácil, flexible, eficiente, etc. que son los sitios web. Los sitios HTML utilizan hipervínculos y formularios como el medio principal de interacción del usuario. Su objetivo principal es permitirnos a nosotros, los clientes, conocer solo aquellos enlaces que podemos usar en el estado actual . Y REST simplemente dice '¿por qué no usar los mismos principios para manejar computadoras en lugar de clientes humanos a través de nuestra aplicación?' Combine esto con el poder de la infraestructura WWW y obtendrá una herramienta excelente para crear excelentes aplicaciones distribuidas.

Otra posible explicación es para las personas que piensan matemáticamente. Cada aplicación es básicamente una máquina de estado con acciones de lógica de negocios que son transiciones de estado. La idea de REST es mapear cada transición en alguna solicitud a un recurso y proporcionar a los clientes enlaces que representen las transiciones disponibles en el estado actual. Por lo tanto, modela la máquina de estados a través de representaciones y enlaces. Es por eso que se llama Transferencia de Estado REpresentacional.

Es sorprendente que todas las respuestas parezcan centrarse en el formato del mensaje o en el uso de verbos HTTP. De hecho, el formato del mensaje no importa en absoluto, REST puede usar cualquiera, siempre que el desarrollador del servicio lo documente. Los verbos HTTP solo hacen que un servicio sea CRUD, pero aún no RESTful. Lo que realmente convierte un servicio en un servicio REST son los hipervínculos (también conocidos como controles hipermedia) integrados en las respuestas del servidor junto con los datos, y su cantidad debe ser suficiente para que cualquier cliente elija la siguiente acción de esos enlaces.

Desafortunadamente, es bastante difícil encontrar información correcta sobre REST en la Web, a excepción de la tesis de Roy Fielding . (Él es el que derivó REST). Recomendaría el libro 'REST in Practice' ya que ofrece un tutorial completo paso a paso sobre cómo pasar de SOAP a REST.

JABÓN

Esta es una de las formas posibles de estilo de arquitectura RPC (llamada a procedimiento remoto). En esencia, es solo una tecnología que permite a los clientes llamar a los métodos del servidor a través de los límites del servicio (red, procesos, etc.) como si llamaran a métodos locales. Por supuesto, en realidad difiere de llamar a métodos locales en velocidad, confiabilidad, etc., pero la idea es así de simple.

Comparado

Los detalles como protocolos de transporte, formatos de mensajes, xsd, wsdl, etc. no importan al comparar cualquier forma de RPC con REST. La principal diferencia es que un servicio RPC reinventa la bicicleta al diseñar su propio protocolo de aplicación en la API RPC con la semántica que solo él conoce. Por lo tanto, todos los clientes deben comprender este protocolo antes de usar el servicio, y no se puede construir una infraestructura genérica como cachés debido a la semántica patentada de todas las solicitudes. Además, las API de RPC no sugieren qué acciones están permitidas en el estado actual, esto debe derivarse de documentación adicional. REST, por otro lado, implica el uso de interfaces uniformes para permitir que varios clientes comprendan la semántica de la API y los controles (enlaces) hipermedia para resaltar las opciones disponibles en cada estado. Así,

En cierto modo, SOAP (como cualquier otro RPC) es un intento de hacer un túnel a través de un límite de servicio tratando los medios de conexión como una caja negra capaz de transmitir mensajes solamente. REST es una decisión de reconocer que la Web es un gran sistema de información distribuida, de aceptar el mundo tal como es y aprender a dominarlo en lugar de luchar contra él.

SOAP parece ser excelente para las API de red interna, cuando controla tanto el servidor como los clientes, y aunque las interacciones no son demasiado complejas. Es más natural que los desarrolladores lo usen. Sin embargo, para una API pública que utilizan muchas partes independientes, es compleja y grande, REST debería ajustarse mejor. Pero esta última comparación es muy confusa.

Actualizar

Mi experiencia inesperadamente ha demostrado que el desarrollo REST es más difícil que SOAP. Al menos para .NET. Si bien existen grandes marcos como ASP.NET Web API, no hay herramientas que generen automáticamente proxy del lado del cliente. Nada como 'Agregar referencia de servicio web' o 'Agregar referencia de servicio WCF'. Uno tiene que escribir todo el código de serialización y consulta de servicio a mano. Y hombre, eso es mucho código repetitivo. Creo que el desarrollo REST necesita algo similar a WSDL y la implementación de herramientas para cada plataforma de desarrollo. De hecho, parece haber un buen terreno: WADL o WSDL 2.0 , pero ninguno de los estándares parece estar bien respaldado.

Actualización (enero de 2016)

Resulta que ahora hay una gran variedad de herramientas para la definición de API REST. Mi preferencia personal es actualmente RAML .

Cómo funcionan los servicios web

Bueno, esta es una pregunta demasiado amplia, porque depende de la arquitectura y la tecnología utilizada en el servicio web específico. Pero, en general, un servicio web es simplemente una aplicación en la Web que puede aceptar solicitudes de clientes y devolver respuestas. Está expuesto a la Web, por lo tanto, es un servicio web y, por lo general, está disponible las 24 horas, los 7 días de la semana, por eso es un servicio . Por supuesto, resuelve algún problema (de lo contrario, ¿por qué alguien usaría un servicio web?) Para sus clientes.

Esta es la explicación más simple que encontrarás.

Este artículo lleva una narración de esposo a esposa, donde el esposo le explica a su esposa sobre REST, en términos puramente laicos. ¡Debe leer!

cómo-he-explicado-descanso-a-mi-esposa (enlace original)
cómo-he-explicado-descanso-a-mi-esposa (enlace de trabajo 2013-07-19)

SOAP - Simple Object Access Protocol es un protocolo !

RESTO - ¡La Transferencia de Estado Representativa es un estilo arquitectónico !

SOAP es un protocolo XML utilizado para transferir mensajes, generalmente a través de HTTP

RESTy SOAPson sin duda no se excluyen mutuamente. Una arquitectura REST podría usar HTTPo SOAPo algún otro protocolo de comunicación. RESTestá optimizado para la web y, por lo tanto, HTTPes una elección perfecta. HTTPes también el único protocolo discutido en el artículo de Roy Fielding.

Aunque REST y SOAP son claramente muy diferente, la pregunta ¿Se ilumina el hecho de que RESTy HTTPse utiliza a menudo en tándem. Esto se debe principalmente a la simplicidad de HTTP y su mapeo muy natural a los principios RESTful.

Principios fundamentales de REST

Comunicación cliente-servidor

Las arquitecturas cliente-servidor tienen una separación muy clara de preocupaciones. Todas las aplicaciones creadas en el estilo RESTful también deben ser, en principio, cliente-servidor.

Apátrida

Cada solicitud de cada cliente al servidor requiere que su estado esté totalmente representado. El servidor debe poder comprender completamente la solicitud del cliente sin utilizar ningún contexto de servidor o estado de sesión del servidor. Se deduce que todo el estado debe mantenerse en el cliente. Discutiremos la representación sin estado con más detalle más adelante.

Caché

Se pueden usar restricciones de caché, lo que permite que los datos de respuesta se marquen como almacenables en caché o no almacenables en caché. Cualquier dato marcado como almacenable en caché puede reutilizarse como respuesta a la misma solicitud posterior.

Interfaz uniforme

Todos los componentes deben interactuar a través de una única interfaz uniforme. Debido a que la interacción de todos los componentes ocurre a través de esta interfaz, la interacción con diferentes servicios es muy simple. ¡La interfaz es la misma! Esto también significa que los cambios de implementación se pueden hacer de forma aislada. Dichos cambios no afectarán la interacción de componentes fundamentales porque la interfaz uniforme siempre no cambia. Una desventaja es que está atascado con la interfaz. Si se pudiera proporcionar una optimización a un servicio específico cambiando la interfaz, no tiene suerte ya que REST lo prohíbe. En el lado positivo, sin embargo, REST está optimizado para la web, por lo tanto, ¡increíble popularidad de REST sobre HTTP!

Los conceptos anteriores representan características definitorias de REST y diferencian la arquitectura REST de otras arquitecturas como los servicios web. Es útil tener en cuenta que un servicio REST es un servicio web, pero un servicio web no es necesariamente un servicio REST.

Ver este blog después de Directores de diseño del resto para más detalles sobre REST y las balas por encima establecidos.

Me gusta la respuesta de Brian R. Bondy. Solo quería agregar que Wikipedia proporciona una descripción clara de REST . El artículo lo distingue de SOAP.

REST es un intercambio de información de estado, realizado de la manera más simple posible.

SOAP es un protocolo de mensaje que usa XML.

Una de las razones principales por las que muchas personas se han mudado de SOAP a REST es que los estándares WS- * (llamados WS splat) asociados con los servicios web basados ​​en SOAP son EXTREMADAMENTE complicados. Consulte wikipedia para obtener una lista de las especificaciones. Cada una de estas especificaciones es muy complicada.

EDITAR: por alguna razón, los enlaces no se muestran correctamente. REST = http://en.wikipedia.org/wiki/REST

WS- * = http://en.wikipedia.org/wiki/WS- *

Tanto los servicios web SOAP como los servicios web REST pueden usar el protocolo HTTP y otros protocolos también (solo por mencionar que SOAP puede ser el protocolo subyacente de REST). Solo hablaré sobre SOAP y REST relacionados con el protocolo HTTP, porque este es el uso más frecuente de ellos.

JABÓN

SOAP (protocolo de acceso a objetos "simple") es un protocolo (y un estándar W3C ). Define cómo crear, enviar y procesar mensajes SOAP.

• Los mensajes SOAP son documentos XML con una estructura específica: contienen un sobre que contiene el encabezado y la sección del cuerpo. El cuerpo contiene los datos reales, que queremos enviar, en formato XML. Hay dos estilos de codificación , pero generalmente elegimos literales , lo que significa que nuestra aplicación o su controlador SOAP realiza la serialización y deserialización XML de los datos.

• Los mensajes SOAP viajan como mensajes HTTP con el subtipo SOAP + XML MIME. Estos mensajes HTTP pueden ser multiparte, por lo que opcionalmente podemos adjuntar archivos a mensajes SOAP.

• Obviamente utilizamos una arquitectura cliente-servidor, por lo que los clientes SOAP envían solicitudes a los servicios web SOAP y los servicios envían respuestas a los clientes. La mayoría de los servicios web utilizan un archivo WSDL para describir el servicio. El archivo WSDL contiene el esquema XML (XSD en adelante) de los datos que queremos enviar y el enlace WSDL que define cómo el servicio web está vinculado al protocolo HTTP. Hay dos estilos de encuadernación.: RPC y documento. Mediante el enlace de estilo RPC, el cuerpo SOAP contiene la representación de una llamada de operación con los parámetros (solicitudes HTTP) o los valores de retorno (respuesta HTTP). Los parámetros y los valores de retorno se validan con el XSD. Por el enlace del estilo del documento, el cuerpo SOAP contiene un documento XML que se valida con el XSD. Creo que el estilo de enlace de documentos se adapta mejor a los sistemas basados ​​en eventos, pero nunca usé ese estilo de enlace. El estilo de enlace RPC es más frecuente, por lo que la mayoría de las personas usan SOAP para fines XML / RPC mediante aplicaciones distribuidas. Los servicios web generalmente se encuentran preguntando a un servidor UDDI . Los servidores UDDI son registros que almacenan la ubicación de los servicios web.

JAP RPC

Entonces, en mi opinión, el servicio web SOAP más frecuente utiliza el estilo de enlace RPC y el estilo de codificación literal y tiene las siguientes propiedades:

• Asigna URL a operaciones.
• Envía mensajes con el subtipo SOAP + XML MIME.
• Puede tener un almacén de sesiones del lado del servidor, no hay restricciones al respecto.
• Los controladores del cliente SOAP usan el archivo WSDL del servicio para convertir las operaciones RPC en métodos. La aplicación del lado del cliente se comunica con el servicio web SOAP llamando a estos métodos. Entonces, la mayoría de los clientes SOAP se separan por cambios en la interfaz (nombres de métodos resultantes y / o cambios de parámetros).
• Es posible escribir clientes SOAP que no se rompan por cambios de interfaz usando RDF y encontrar operaciones por semántica, pero el servicio web semántico es muy raro y no necesariamente tienen un cliente que no se rompa (supongo).

DESCANSO

REST (transferencia de estado de representación) es un estilo de arquitectura que se describe en la disertación de Roy Fielding. No le preocupan los protocolos como lo hace SOAP. Comienza con un estilo de arquitectura nulo que no tiene restricciones y define las restricciones de la arquitectura REST una por una. Las personas usan el término RESTful para servicios web que cumplen con todas las restricciones REST, pero según Roy Fielding, no existen los niveles REST . Cuando un servicio web no cumple con todas las restricciones REST, entonces no es un servicio web REST.

Restricciones REST

• Cliente - arquitectura del servidor - Creo que esta parte es familiar para todos. Los clientes REST se comunican con los servicios web REST, los servicios web mantienen los datos comunes, el estado de los recursos en lo sucesivo, y los sirven a los clientes.
• Sin estado: la parte de la abreviatura "transferencia de estado": REST. Los clientes mantienen el estado del cliente (estado de sesión / aplicación), por lo que los servicios no deben tener un almacenamiento de sesión. Los clientes transfieren la parte relevante del estado del cliente por cada solicitud a los servicios que responden con la parte relevante del estado del recurso (mantenida por ellos). Por lo tanto, las solicitudes no tienen contexto, siempre contienen la información necesaria para procesarlas. Por ejemplo, mediante autenticación básica HTTP, el nombre de usuario y la contraseña son almacenados por el cliente, y los envía con cada solicitud, por lo que la autenticación ocurre con cada solicitud. Esto es muy diferente de las aplicaciones web normales en las que la autenticación solo se realiza al iniciar sesión. Podemos usar cualquier mecanismo de almacenamiento de datos del lado del cliente como en memoria (javascript), cookies, localStorage, etc. persistir algunas partes del estado del cliente si queremos. La razón de la restricción de apatridia es que el servidor escala bien, incluso con una carga muy alta (millones de usuarios), cuando no tiene que mantener la sesión de cada cliente.
• Caché: la respuesta debe contener información que el cliente pueda almacenar en caché o no. Esto mejora aún más la escalabilidad.

• Interfaz uniforme

  • Identificación de recursos: el recurso REST es el mismo que el recurso RDF . Según Fielding, si puede nombrar algo, puede ser un recurso, por ejemplo: "el clima local actual" puede ser un recurso, o "su teléfono móvil" puede ser un recurso, o "un documento web específico" puede ser un recurso. Para identificar un recurso, puede usar identificadores de recursos: URL y URN (por ejemplo, número ISBN por libros ). Un solo identificador debe pertenecer solo a un recurso específico, pero un solo recurso puede tener muchos identificadores, que con frecuencia explotamos, por ejemplo, mediante paginación con URL como https://example.com/api/v1/users?offset=50&count=25. Las URL tienen algunas especificaciones, por ejemplo, las URL con las mismas rutas pero las consultas diferentes no son idénticas, o la parte de la ruta debe contener los datos jerárquicos de la URL y la parte de la consulta debe contener los datos no jerárquicos. Estos son los conceptos básicos sobre cómo crear URL mediante REST. Por cierto. la estructura de URL solo es importante para los desarrolladores de servicios, un cliente REST real no se preocupa por ella. Otra pregunta frecuente es el control de versiones de API, que es fácil, porque según Fielding lo único constante por recurso es la semántica. Si la semántica cambia, puede agregar un nuevo número de versión. Puede usar versiones clásicas de 3 números y agregar solo el número principal a las URL (https://example.com/api/v1/) Por lo tanto, con los cambios compatibles con versiones anteriores no sucede nada, con los cambios no compatibles con versiones anteriores tendrá una semántica no compatible con versiones anteriores con una nueva raíz API https://example.com/api/v2/. Por lo tanto, los antiguos clientes no se romperán, porque pueden usar el https://example.com/api/v1/con la antigua semántica.
  • Manipulación de recursos a través de representaciones: puede manipular los datos relacionados con los recursos (estado de los recursos) enviando la representación prevista de los recursos, junto con el método HTTP y el identificador de recursos, al servicio REST. Por ejemplo, si desea cambiar el nombre de un usuario después del matrimonio, puede enviar una PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"}solicitud donde {name: "Mrs Smith"}sea ​​una representación JSON del estado del recurso deseado, en otras palabras: el nuevo nombre. Esto sucede vica-versa, el servicio envía representaciones de recursos a los clientes para cambiar sus estados. Por ejemplo, si queremos leer el nuevo nombre, podemos enviar una GET https://example.com/api/v1/users/1?fields="name"solicitud de recuperación, que da como resultado un200 ok, {name: "Mrs Smith"}respuesta. Por lo tanto, podemos usar esta representación para cambiar el estado del cliente, por ejemplo, podemos mostrar un mensaje "¡Bienvenido a nuestra página, Sra. Smith!" mensaje. Un recurso puede tener muchas representaciones según el identificador de recurso (URL) o el acceptencabezado que enviamos con la solicitud. Por ejemplo, podemos enviar una imagen de la Sra. Smith (probablemente no desnuda) si image/jpegse solicita.
  • Mensajes autodescriptivos: los mensajes deben contener información sobre cómo procesarlos. Por ejemplo, método URI y HTTP, encabezado de tipo de contenido, encabezados de caché, RDF que describe el significado de los datos, etc. Es importante utilizar métodos estándar. Es importante conocer la especificación de los métodos HTTP. Por ejemplo, GET significa recuperar información identificada por la URL de solicitud, DELETE significa pedirle al servidor que elimine el recurso identificado por la URL dada, y así sucesivamente ... Los códigos de estado HTTP también tienen una especificación , por ejemplo 200 significa éxito, 201 significa Si se ha creado un nuevo recurso, 404 significa que el recurso solicitado no se encontró en el servidor, etc. El uso de estándares existentes es una parte importante de REST.

  • Hypermedia como el motor del estado de la aplicación (HATEOAS en adelante): Hypermedia es un tipo de medio que puede contener hipervínculos. En la web seguimos los enlaces, descritos por un formato hipermedia (generalmente HTML), para lograr un objetivo, en lugar de escribir las URL en la barra de direcciones. REST sigue el mismo concepto, las representaciones enviadas por el servicio pueden contener hipervínculos. Utilizamos estos hipervínculos para enviar solicitudes al servicio. Con la respuesta obtenemos datos (y probablemente más enlaces) que podemos usar para construir el nuevo estado del cliente, y así sucesivamente ... Por eso, hipermedia es el motor del estado de la aplicación (estado del cliente). Probablemente se pregunte cómo los clientes reconocen y siguen los hipervínculos. Para los humanos es bastante simple, leemos el título del enlace, tal vez rellenemos los campos de entrada y, después de eso, solo un clic.JSON-LD con Hydra ) o con soluciones específicas de hipermedia (por ejemplo, relaciones de enlace IANA y tipos MIME específicos del proveedor por HAL + JSON ). Hay muchos formatos de hipermedia XML y JSON legibles por máquina , solo una breve lista de ellos:

    • XHTML
    • ATOM + XML
    • RDF + XML
    • HAL + XML
    • HAL + JSON
    • JSON-LD
    • RDF + JSON
    • Sirena
    • Colección + JSON

    A veces es difícil elegir ...

• Sistema en capas: podemos usar varias capas entre los clientes y los servicios. Ninguno de ellos debería saber acerca de todas estas capas adicionales, solo de la capa justo al lado. Estas capas pueden mejorar la escalabilidad mediante la aplicación de cachés y el equilibrio de carga o pueden aplicar políticas de seguridad.
• Código bajo demanda: podemos devolver el código que extiende la funcionalidad del cliente, por ejemplo, el código JavaScript a un navegador. Esta es la única restricción opcional de REST.

Servicio web REST - Diferencias del servicio web SOAP RPC

Por lo tanto, un servicio web REST es muy diferente de un servicio web SOAP (con estilo de enlace RPC y estilo de codificación literal)

• Define una interfaz uniforme (intead de un protocolo).
• Asigna URL a recursos (y no a operaciones).
• Envía mensajes con cualquier tipo MIME (en lugar de solo SOAP + XML).
• Tiene una comunicación sin estado, por lo que no puede tener un almacenamiento de sesión del lado del servidor. (SOAP no tiene restricciones sobre esto)
• Sirve a hipermedia y los clientes usan enlaces contenidos por ese hipermedia para solicitar el servicio. (SOAP RPC utiliza enlaces de operación descritos en el archivo WSDL)
• No se divide por cambios de URL solo por cambios semánticos. (Los clientes RPC SOAP sin utilizar la semántica RDF se rompen por los cambios en el archivo WSDL).
• Se escala mejor que un servicio web SOAP debido a su comportamiento sin estado.

y así...

Un servicio web SOAP RPC no cumple con todas las restricciones REST:

• arquitectura cliente-servidor - siempre
• apátrida - posible
• caché - posible
• interfaz uniforme - nunca
• sistema en capas - nunca
• código bajo demanda (opcional) - posible

Bueno, comenzaré con la segunda pregunta: ¿Qué son los servicios web? , por obvias razones.

Los servicios web son esencialmente piezas lógicas (a las que puede referirse vagamente como un método) que exponen cierta funcionalidad o datos. El cliente que implementa (técnicamente hablando, consumir es la palabra) solo necesita saber cuáles son los parámetros que el método aceptará y el tipo de datos que devolverá (si es que lo hace).

El siguiente enlace lo dice todo sobre REST & SOAP de una manera extremadamente lúcida.

RESTO vs JABÓN

Si también desea saber cuándo elegir qué (DESCANSO o JABÓN), ¡más razones para hacerlo!

SOAP y REST se refieren a formas en que diferentes sistemas se comunican entre sí.

REST hace esto usando técnicas que se parecen a la comunicación que tiene su navegador con los servidores web: usar GET para solicitar una página web, PUBLICAR en campos de formulario, etc.

SOAP proporciona algo similar, pero lo hace todo mediante el envío de bloques de XML de un lado a otro. Otro componente clave de SOAP es WSDL, que es un documento XML que describe qué funciones y elementos de datos son compatibles. Los WSDL se pueden usar para "descubrir" mediante programación qué funciones son compatibles, así como para generar código auxiliar de programación.

Creo que esto es tan fácil como puedo explicarlo. Por favor, cualquiera puede corregirme o agregar algo a esto.

SOAP es un formato de mensaje utilizado por los sistemas desconectados (como en Internet) para intercambiar información / datos. Lo hace con mensajes XML yendo y viniendo.

Los servicios web transmiten o reciben mensajes SOAP. Funcionan de manera diferente según el idioma en el que se escriben.

El problema con SOAP es que está en conflicto con los ideales detrás de la pila HTTP. Cualquier middleware debería poder trabajar con solicitudes HTTP sin comprender el contenido de la solicitud o respuesta, pero, por ejemplo, un servidor de almacenamiento en caché HTTP normal no funcionará con solicitudes SOAP sin saber qué partes del contenido SOAP son importantes para el almacenamiento en caché. SOAP solo usa HTTP como envoltorio para su propio protocolo de comunicaciones, como un proxy.

REST es un estilo de arquitectura para diseñar aplicaciones en red. La idea es que, en lugar de utilizar mecanismos complejos como CORBA, RPC o SOAP para conectarse entre máquinas, se use HTTP simple para hacer llamadas entre máquinas.

SOAP - "Protocolo simple de acceso a objetos"

SOAP es un poco de transferencia de mensajes, o pequeñas cantidades de información a través de Internet. Los mensajes SOAP están formateados en XML y generalmente se envían controlando HTTP .

RESTO - "Transferencia de estado representativa"

REST es un proceso rudimentario de eventualidad y recepción de información entre el ventilador y el servidor y no tiene inequívocamente muchos estándares definidos. Puede enviar y aceptar información como JSON , XML o incluso texto sin formato. Es ligero en comparación con SOAP .

Servicios web basados ​​en SOAP En resumen, el modelo de servicios basados ​​en SOAP ve el mundo como un ecosistema de pares iguales que no pueden controlarse entre sí, pero que tienen que trabajar juntos cumpliendo los contratos publicados. Es un modelo válido del mundo real desordenado, y los contratos basados ​​en metadatos forman la interfaz de servicio SOAP.

todavía podemos asociar SOAP con llamadas de procedimiento remoto basadas en XML, pero la tecnología de servicios web basada en SOAP se ha convertido en un modelo de mensajería flexible y potente.

SOAP asume que todos los sistemas son independientes y ningún sistema tiene conocimiento de lo interno de otra funcionalidad interna. Lo más que pueden hacer estos sistemas es enviarse mensajes entre sí y esperar que se actúe sobre ellos. Los sistemas publican contratos que se comprometen a cumplir, y otros sistemas confían en estos contratos para intercambiar mensajes con ellos.

Los contratos entre sistemas se denominan colectivamente metadatos y comprenden descripciones de servicios, los patrones de intercambio de mensajes admitidos y las políticas que rigen las cualidades del servicio (un servicio puede ser encriptado, entregado de manera confiable, etc.) Una descripción del servicio, a su vez, es detallada especificación de los datos (documentos del mensaje) que serán enviados y recibidos por el sistema. Los documentos se describen utilizando un lenguaje de descripción XML como XML Schema Definition. Mientras todos los sistemas cumplan con sus contratos publicados, pueden interactuar y los cambios en los componentes internos de los sistemas nunca afectan a ningún otro. Cada sistema es responsable de traducir sus propias implementaciones internas hacia y desde sus contratos

RESTO - Transferencia representativa del estado. El protocolo físico es HTTP. Básicamente, REST es que todos los recursos distintos en la web son identificables de manera única por una URL. Todas las operaciones que se pueden realizar en estos recursos se pueden describir mediante un conjunto limitado de verbos (los verbos "CRUD") que a su vez se asignan a verbos HTTP.

REST es mucho menos "pesado" que SOAP.

Funcionamiento del servicio web