servicios services restful que protocol example entre ejemplo diferencia arquitectura rest soap

services - Transferencia de estado representacional(REST) y Protocolo simple de acceso a objetos(SOAP)



rest web services (14)

¿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 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 mediante HTTP (protocolo de transferencia de hipertexto).

Resto - transferencia de estado representacional

El descanso es una forma sencilla 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. Es ligero ponderado en comparación con el jabón.

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 construye 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, normalmente alimenta 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 el codificado en base64.
  • Tiene varios protocolos y tecnologías relacionadas con él: WSDL, XSDs, SOAP, WS-Addressing

Transferencia de estado representacional (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 que espere un minuto, no necesitamos toda esta complejidad que creó SOAP.
  • Por lo general, utiliza métodos HTTP normales en lugar de un gran formato XML que describe todo. Por ejemplo, para obtener un recurso, use HTTP GET, para poner un recurso en el servidor que usa HTTP PUT. Para eliminar un recurso en el servidor, use HTTP DELETE.
  • REST es muy simple porque utiliza los métodos HTTP GET, POST y PUT para actualizar los recursos en el servidor.
  • Por lo general, REST se utiliza 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 sí, puede consumir un protocolo REST HTTP con mucha facilidad.
  • Los datos binarios o los recursos binarios se pueden entregar simplemente a su solicitud.

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 PDF en CiteSeerX .

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

Los servicios web son esencialmente piezas de lógica (a las que puede referirse vagamente como un método) que exponen cierta funcionalidad o datos. La implementación del cliente (técnicamente hablando, consumiendo 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 acerca de REST & SOAP de una manera extremadamente lúcida.

REST vs SOAP

Si también quieres saber cuándo elegir qué (REST o SOAP), ¡más razón para hacerlo!

Creo que esto es tan fácil como puedo explicarlo. Por favor, cualquier persona es bienvenida a corregirme o agregar a esto.

SOAP es un formato de mensaje utilizado por los sistemas desconectados (como a través de Internet) para intercambiar información / datos. Lo hace con los mensajes XML que van y vienen.

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

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 la respuesta, pero, por ejemplo, un servidor de almacenamiento en caché HTTP regular no funcionará con solicitudes SOAP sin saber solo 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.

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

Este artículo lleva la narrativa de marido a mujer, donde el marido le explica a su esposa sobre REST, en términos puramente laicos. ¡Debe leer!

how-i-explained-rest-to-my-wife (enlace original)
how-i-explained-rest-to-my-wife (enlace de trabajo 2013-07-19)

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 del jabón.

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

SOAP es un protocolo de mensajes que utiliza XML.

Una de las razones principales por las que muchas personas se han movido de SOAP a REST es que los estándares WS- * (llamados WS splat) asociados con los servicios web basados ​​en SOAP son EXTREMADAMENTE complicados. Ver 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 = REST

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

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 utiliza HTTP simple para hacer llamadas entre máquinas.

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

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

SOAP proporciona algo similar pero hace todo a través del 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" de manera programática qué funciones son compatibles, así como para generar apéndices de código de programación.

Tanto los servicios web SOAP como los servicios web REST pueden usar el protocolo HTTP y otros protocolos (solo para mencionar que SOAP puede ser el protocolo subyacente de REST). Solo hablaré sobre el protocolo HTTP relacionado con SOAP y REST, 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, queremos enviar, en un formato XML. Hay dos estilos de codificación , pero normalmente elegimos literal , lo que significa que nuestra aplicación o su controlador SOAP realizan la serialización XML y la deserialización 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 valores de retorno son validados contra el XSD. Por el enlace del estilo del documento, el cuerpo de SOAP contiene un documento XML que se valida contra el XSD. Creo que el estilo de enlace del documento se adapta mejor a los sistemas basados ​​en eventos, pero nunca usé ese estilo de enlace. El estilo de enlace de RPC es más frecuente, por lo que la mayoría de las personas utilizan SOAP para fines de XML / RPC por aplicaciones distribuidas. Los servicios web generalmente se encuentran entre sí preguntando a un servidor UDDI . Los servidores UDDI son registros que almacenan la ubicación de los servicios web.

SOAP RPC

Así que, 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 direcciones URL a las operaciones.
  • Envía mensajes con subtipo SOAP + XML MIME.
  • Puede tener un almacén de sesión del lado del servidor, no hay restricciones al respecto.
  • Los controladores de cliente SOAP utilizan 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. Así que la mayoría de los clientes SOAP se rompen por los cambios de interfaz (nombres de métodos y / o cambios de parámetros resultantes).
  • Es posible escribir clientes SOAP que no rompan con los cambios de interfaz usando RDF y encuentren operaciones por semántica, pero el servicio web semántico es muy raro y no necesariamente tienen un cliente sin ruptura (supongo).

DESCANSO

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

Restricciones REST

  • Cliente - arquitectura de 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 a continuación) y los entregan a los clientes.
  • Sin estado - La parte de "transferencia de estado" de la abreviatura: REST. Los clientes mantienen el estado del cliente (sesión / estado de la 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 de HTTP, el cliente almacena el nombre de usuario y la contraseña, y los envía con cada solicitud, de modo que la autenticación se realiza con cada solicitud. Esto es muy diferente de las aplicaciones web normales en las que la autenticación solo se realiza mediante el inicio de sesión. Podemos usar cualquier mecanismo de almacenamiento de datos del lado del cliente como en memoria (javascript), cookies, almacenamiento local, etc. para persistir algunas partes del estado del cliente si queremos. La razón de la restricción de apatridia es que el servidor se adapta 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 acerca de ella puede ser almacenada en caché por el cliente o no. Esto mejora la escalabilidad aún más.

  • Interfaz uniforme

    • Identificación de recursos: el recurso REST es el mismo que el recurso RDF . Según Fielding, si puede nombrar algo, entonces 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 de ISBN por libros ). Un solo identificador debe pertenecer solo a un recurso específico, pero un solo recurso puede tener muchos identificadores, que a menudo explotamos, por ejemplo, mediante paginación con URL como https://example.com/api/v1/users?offset=50&count=25 . Las URL tienen algunas specifications , por ejemplo, las URL con las mismas rutas pero diferentes consultas 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 de cómo crear URL por REST. Por cierto La estructura de la URL no importa solo para los desarrolladores de servicios, un cliente REST real no se preocupa por ello. Otra pregunta frecuente es la creación de versiones de API, que es fácil, porque según Fielding, la única cosa constante por recurso es la semántica. Si la semántica cambia, entonces puede agregar un nuevo número de versión. Puede usar la versión clásica de 3 números y agregar solo el número mayor a las URL ( https://example.com/api/v1/ ). Por lo tanto, con los cambios compatibles con versiones anteriores no sucede nada, los cambios no compatibles con versiones anteriores tendrán una semántica no compatible con versiones anteriores con una nueva raíz de API https://example.com/api/v2/ . Por lo tanto, los antiguos clientes no se romperán, porque pueden usar https://example.com/api/v1/ con la semántica antigua.
    • Manipulación de recursos mediante 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 de contraer matrimonio, puede enviar un PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"} solicitud donde la {name: "Mrs Smith"} es una representación JSON del estado del recurso deseado, en otras palabras: el nuevo nombre. Esto sucede a la inversa, 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 solicitud de recuperación GET https://example.com/api/v1/users/1?fields="name" , que resulta en un 200 ok, {name: "Mrs Smith"} respuesta. Así que podemos usar esta representación para cambiar el estado del cliente, por ejemplo, podemos mostrar un mensaje de "¡Bienvenido a nuestra página, señora Smith!" mensaje. Un recurso puede tener muchas representaciones según el identificador de recurso (URL) o el encabezado de accept que enviamos con la solicitud. Por ejemplo, podemos enviar una imagen de la Sra. Smith (probablemente no desnuda) si se solicita una image/jpeg .
    • Mensajes autodescriptivos: los mensajes deben contener información sobre cómo procesarlos. Por ejemplo, los métodos URI y HTTP, encabezado de tipo de contenido, encabezados de caché, RDF que describe el significado de los datos, etc. Es importante usar métodos estándar. Es importante conocer la specification de los métodos HTTP. Por ejemplo, GET significa recuperar información identificada por la URL de solicitud, BORRAR 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 specification , por ejemplo, 200 significa éxito, 201 significa 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.

    • Hipermedia como motor del estado de la aplicación (HATEOAS en lo sucesivo) - Hipermedia es un tipo de medio que puede contener hipervínculos. En la web seguimos los enlaces, descritos por un formato de 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 de cliente, y así sucesivamente ... Por eso es que la 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, con un solo clic. Por máquinas tenemos que agregar semántica a los enlaces con RDF (por 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:

      A veces es difícil elegir ...

  • Sistema de capas: podemos utilizar varias capas entre los clientes y los servicios. Ninguno de ellos debe conocer todas estas capas adicionales, solo las capas que están 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 a pedido: podemos devolver el código que amplía 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 de 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 (en lugar de un protocolo).
  • Asigna direcciones URL a recursos (y no a operaciones).
  • Envía mensajes con cualquier tipo de 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 ninguna restricción sobre esto)
  • Sirve hipermedia y los clientes usan enlaces contenidos en esa hipermedia para solicitar el servicio. (SOAP RPC utiliza los enlaces de operación descritos en el archivo WSDL)
  • No se rompe por cambios de URL solo por cambios semánticos. (Los clientes SOAP RPC sin usar semántica RDF se interrumpen 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
  • sin estado - possible
  • caché - possible
  • interfaz uniforme - nunca
  • sistema de capas - possible
  • Código bajo demanda (opcional) - posible

SOAP - "Protocolo simple de acceso a objetos"

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

RESTO - "Transferencia de Estado Representativa"

REST es un procedimiento rudimentario de eventualidad y recepción de información entre el fan 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 ponderado en comparación con el jabón .

DESCANSO

Entiendo que la idea principal de REST es extremadamente simple. Hemos utilizado navegadores web durante años y hemos visto lo fáciles, flexibles, de rendimiento, etc. que son los sitios web. Los sitios HTML utilizan hipervínculos y formularios como el principal medio de interacción del usuario. Su principal objetivo es permitirnos, clientes, conocer solo los enlaces que podemos usar en el estado actual . Y REST simplemente dice ''¿por qué no usar los mismos principios para conducir a las computadoras en lugar de a los clientes humanos a través de nuestra aplicación?'' Combine esto con el poder de la infraestructura WWW y obtendrá una herramienta extraordinaria 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 representan las transiciones disponibles en el estado actual. Así modela la máquina de estado a través de representaciones y enlaces. Es por esto que se llama Transferencia Estatal Representativa.

Es bastante 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 un servicio CRUD, pero aún no es REST. Lo que realmente convierte un servicio en un servicio REST son los hipervínculos (también conocidos como controles de 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 vínculos.

Desafortunadamente, es bastante difícil encontrar información correcta sobre REST en la Web, excepto por la ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm . (Él es el que obtuvo REST). Recomendaría el libro ''REST in Practice'', ya que ofrece un tutorial detallado paso a paso sobre cómo evolucionar de SOAP a REST.

JABÓN

Esta es una de las formas posibles del 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 estuvieran llamando a métodos locales. Por supuesto, en realidad difiere de los métodos locales en velocidad, confiabilidad y demás, pero la idea es así de simple.

Comparado

Los detalles como los protocolos de transporte, formatos de mensajes, xsd, wsdl, etc. no importan cuando se compara cualquier forma de RPC a REST. La principal diferencia es que un servicio RPC reinventa la bicicleta al diseñar su propio protocolo de aplicación en la API de RPC con la semántica que solo él conoce. Por lo tanto, todos los clientes deben entender este protocolo antes de usar el servicio, y no se puede construir una infraestructura genérica como cachés debido a la semántica de propiedad 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. Por otra parte, REST implica el uso de interfaces uniformes para permitir que varios clientes tengan cierta comprensión de la semántica de la API y los controles de hipermedia (enlaces) para resaltar las opciones disponibles en cada estado. Por lo tanto, permite el almacenamiento en caché de respuestas para servicios de escala y hacer que el uso correcto de la API sea fácilmente detectable sin documentación adicional.

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 que trata a los medios de conexión como una caja negra capaz de transmitir mensajes solamente. REST es una decisión para reconocer que la Web es un gran sistema de información distribuida, para aceptar el mundo tal como es y aprender a dominarlo en lugar de luchar contra él.

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

Actualizar

Mi experiencia ha demostrado inesperadamente que el desarrollo de REST es más difícil que SOAP. Al menos para .NET. Si bien existen grandes marcos como la API web de ASP.NET, no hay herramientas que generen automáticamente el proxy del lado del cliente. Nada como ''Agregar referencia de servicio web'' o ''Agregar referencia de servicio WCF''. Uno tiene que escribir a mano todo el código de serialización y consulta de servicio. Y hombre, eso es un montón de 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 una buena base: WADL o WSDL 2.0 , pero ninguno de los estándares parece estar bien respaldado.

Actualización (enero 2016)

Resulta que ahora hay una gran variedad de herramientas para la definición de la 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 los clientes y responder. 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?

SOAP - Simple Object Access Protocol es un protocolo !

¡REST - Representación estatal de transferencia es un estilo arquitectónico !

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

REST duda, REST y SOAP son mutuamente excluyentes. Una arquitectura REST puede usar HTTP o SOAP o algún otro protocolo de comunicación. REST está optimizado para la web y, por lo tanto, HTTP es una opción perfecta. HTTP es también el único protocolo discutido en el artículo de Roy Fielding.

Aunque REST y SOAP son claramente muy diferentes, la pregunta ilumina el hecho de que REST y HTTP se usan a menudo en tándem. Esto se debe principalmente a la simplicidad de HTTP y su mapeo muy natural a los principios REST.

Principios fundamentales de REST

Comunicación cliente-servidor

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

Apátrida

Cada solicitud de cada cliente al servidor requiere que su estado esté completamente 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. De ello se deduce que todo estado debe mantenerse en el cliente. Discutiremos la representación sin estado en más detalle más adelante.

Cacheable

Se pueden usar restricciones de caché, permitiendo así que los datos de respuesta se marquen como cacheables o no cacheables. 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 toda la interacción de 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 los componentes fundamentales porque la interfaz uniforme siempre se mantiene sin cambios. Una desventaja es que estás 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, ¡una popularidad increíble de REST a través de HTTP!

Los conceptos anteriores representan las 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.

Consulte esta publicación del blog sobre Principios de diseño de REST para obtener más detalles sobre REST y las viñetas indicadas anteriormente.

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

aún podemos asociar SOAP con llamadas a procedimientos remotos basadas en XML, pero la tecnología de servicios web basada en SOAP ha surgido en un modelo de mensajería flexible y poderoso.

SOAP asume que todos los sistemas son independientes y ningún sistema tiene conocimiento de las funciones internas de otro y de la funcionalidad interna. Lo que más pueden hacer estos sistemas es enviar mensajes entre ellos y esperar que se actúe en consecuencia. Los sistemas publican los contratos que se comprometen a cumplir, y otros sistemas dependen de estos contratos para intercambiar mensajes con ellos.

Los contratos entre sistemas se denominan colectivamente metadatos y comprenden descripciones de servicio, patrones de intercambio de mensajes compatibles y las políticas que rigen las calidades de servicio (un servicio puede necesitar cifrado, entrega confiable, etc.) Una descripción del servicio, a su vez, es una descripción detallada. Especificación de los datos (documentos de mensaje) que serán enviados y recibidos por el sistema. Los documentos se describen utilizando un lenguaje de descripción XML como la definición de esquema XML. Siempre que todos los sistemas cumplan con sus contratos publicados, pueden interactuar y los cambios en los aspectos 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 de Estado Representativa. El protocolo físico es HTTP. Básicamente, REST es que todos los recursos distintos en la web que son identificables de forma ú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 el jabón.

Trabajo de servicio web.