X
BLOG

SOAP vs REST: Resolviendo los desafíos de prueba de cada uno

SOAP vs REST: Resolviendo los desafíos de prueba de cada uno Tiempo de leer: 11 minutos

La diferencia entre SOAP y REST API. Quizás ya esté familiarizado con SOAP y REST, y busque expandir sus conocimientos u obtener una nueva perspectiva. O tal vez escuchó sobre ellos y está tratando de comprenderlos mejor. Después de todo, SOAP y REST están bien establecidos con definiciones y especificaciones que se remontan a décadas.

Permítame describir la diferencia SOAP y REST, comparar y, de lo contrario, arrojar luz sobre estos dos enfoques importantes para el servicio web y el diseño de API web. También destacaré algunos de los desafíos de prueba asociados con estos enfoques y cómo resolverlos. Primero, definamos qué son y cómo se relacionan con la World Wide Web.

Diferencia entre servicios web SOAP y REST

La Consorcio World Wide Web (W3C) recomienda estándares y protocolos para la colección global de recursos interconectados que conocemos como World Wide Web. Se accede a un recurso "web" en una dirección "web" y se entrega a través de un protocolo "web".

Como alguien que lee esta publicación de blog, es posible que sepa que está leyendo un documento HTML en el URI que se muestra en la barra de direcciones de su navegador que se solicitó y entregó mediante el protocolo HTTP (S). El W3C definió cómo estas mismas tecnologías que le permiten leer esta publicación de blog pueden facilitar la comunicación entre sistemas de software. En particular, el W3C definió los "servicios web", lo que llevó a la creación de muchos otros estándares y tecnologías a lo largo de los años. Echemos un vistazo de alto nivel a lo que son.

JABÓN Simple Object Access Protocol es un protocolo orientado a objetos mediante el cual los objetos se intercambian entre el cliente y el servidor, serializados hacia y desde XML. La especificación SOAP se basa en otras tecnologías "web" definidas por el W3C, incluidos XML y HTTP. Muchas especificaciones se basan o amplían la especificación SOAP, incluidas algunas que no son tan “simples”. Un servicio SOAP intercambia mensajes SOAP con un cliente SOAP. Un mensaje SOAP también se denomina "sobre". Un sobre SOAP tiene un elemento "Cuerpo" y un elemento "Encabezado" opcional. El "Cuerpo" normalmente envuelve o literalmente "envuelve" otro documento XML. Una solicitud SOAP también indica la operación o acción que se invoca. Diferentes operaciones aceptan y devuelven diferentes tipos de documentos.
RESTO Transferencia de estado representacional. A diferencia de SOAP, REST no es una tecnología específica, sino un estilo arquitectónico, que define restricciones específicas para un sistema de software. Un servicio web o API web compatible con REST a menudo se conoce como API RESTful o API REST. El propósito de una API REST es intercambiar representaciones de un recurso. Un recurso puede ser cualquier tipo de entidad que pueda identificarse conceptualmente mediante un URI. Una API REST escucha en un URI base con rutas secundarias para acceder a cada uno de los recursos expuestos por la API. Una ruta de recursos puede incluir uno o más parámetros que se pueden usar para identificar un recurso, donde ciertos segmentos de ruta podrían contener identificadores. Los parámetros de recursos también pueden tomar la forma de parámetros de consulta o encabezados. Una API REST expone una o más operaciones CRUD para recuperar o manipular un recurso (crear, recuperar, actualizar y eliminar).

Ahora, profundicemos en algunos detalles sobre la diferencia entre el jabón y el descanso, entendiendo cómo estos enfoques se comparan entre sí.

Operaciones

Un servicio SOAP define un conjunto de operaciones. Las operaciones pueden ser arbitrarias en el sentido de que no existen restricciones en el alcance o propósito de las operaciones que se definen. Las operaciones tienen una firma, típicamente representativa del nombre completo del elemento dentro del elemento Cuerpo del sobre. Por ejemplo, el nombre del elemento podría ser "calcular algo" o "hacer algo divertido".

Una API REST tiene una colección de operaciones para cada recurso. Las operaciones que están disponibles se limitan a CRUD (crear, recuperar, actualizar y eliminar). Las operaciones se asignan a métodos HTTP como GET, POST, PUT, PATCH y DELETE.

Comparación positiva

JABÓN Las operaciones SOAP ofrecen un mayor grado de flexibilidad, ya que no se limitan a CRUD y no tienen que estructurarse en torno a tipos de recursos específicos como REST. Sin embargo, las operaciones también se pueden usar para CRUD, donde el XML en el cuerpo SOAP puede incluir una representación XML de un objeto junto con su identificador.
RESTO Las operaciones REST ofrecen un mayor grado de simplicidad. Se utiliza un URI para identificar el recurso, desacoplado de la representación del recurso que se intercambia. Además, las operaciones deben ser sin estado, lo que significa que las operaciones se comportan de manera coherente y no se basan en el estado de la conversación entre el cliente y el punto final del servicio.

Comparación crítica

JABÓN Los servicios SOAP pueden tener una complejidad mucho mayor al admitir operaciones arbitrarias y al potencialmente rastrear el estado. Un ejemplo podría ser un servicio de librería que tenga una operación "addToCart". Cada vez que un cliente llama "addToCart", el servicio rastrea el artículo en el carrito de compras del cliente. Un cliente diferente puede llamar "addToCart" y no afectar el carrito de compras de otro cliente. El servicio rastrea el estado de cada cliente por separado.
RESTO Las API REST están más restringidas que SOAP al tener operaciones limitadas a CRUD. Además, los clientes tienen la carga de rastrear su propio estado. En el ejemplo de la librería, el cliente necesita conocer el ID de su carrito para poder construir el URI correcto para su carrito de compras, como "carrito / {id}". El cliente podría realizar un GET en ese URI para obtener una representación estructurada de su carrito. El cliente también podría hacer un PUT en ese mismo URI para actualizar su carrito con una representación actualizada.

Representación de datos

La mensajería SOAP implica el intercambio de documentos XML denominados sobres SOAP. Un sobre SOAP contiene un elemento "Cuerpo" y un elemento "Encabezado" opcional. El XML dentro del elemento "Body" puede ser arbitrario, pero normalmente representa una o más entidades u objetos. El tipo de contenido es “texto / xml” o “aplicación / jabón + xml” dependiendo de si se está siguiendo la versión 1.1 de SOAP o la versión 1.2 de SOAP. Los elementos XML en SOAP también se pueden usar para envolver otros tipos de datos, textuales o binarios. Los métodos definidos por el W3C llamados “XOP” y “MTOM” describen cómo empaquetar de manera eficiente datos binarios en mensajes XML y SOAP como un MIME “Multiparte / Related”, evitando la necesidad de codificar en base64 los datos binarios directamente dentro de las etiquetas XML.

La mensajería de la API REST implica el intercambio de representaciones de un recurso. Una "representación" puede ser cualquier formato de datos. Podría ser un formato de intercambio / intercambio de datos estructurados como XML o JSON, o algo completamente diferente como PDF o JPEG. No hay restricción de tipo de contenido. Una API REST podría admitir múltiples formatos de datos o diferentes formatos de datos para diferentes recursos.

Comparación positiva

JABÓN XML está estandarizado y bien entendido, definido por varias recomendaciones del W3C. XML tiene un concepto de espacios de nombres, que ayudan a eliminar la ambigüedad de los elementos, evitando conflictos de nombres. Los sobres SOAP proporcionan una capa de encapsulación, lo que permite la inclusión de metadatos adicionales en el elemento "Encabezado".
RESTO Las API REST no están restringidas en términos de los formatos de datos que pueden usar. Para los datos estructurados, el uso de JSON es común y mucho más rápido de consumir y producir que XML. Sin embargo, existen otros formatos para serializar datos estructurados que pueden ser incluso más compactos y eficientes que JSON, como BSON (JSON binario) o de Google Búferes de protocolo (Protobuf). Cualquier tipo de contenido es una posibilidad.

Comparación crítica

JABÓN XML también puede ser detallado o inflado en comparación con otros formatos de datos con un costo de serialización relativamente alto tanto para producir como para consumir. Sin embargo, el tamaño del mensaje se puede reducir mediante la compresión como el esquema de compresión HTTP "Content-Encoding: gzip". El costo de serialización se puede reducir mediante el uso de codificaciones XML binarias o alternativas, como las de Microsoft. Formato binario .NET para XML.
RESTO No existe un formato de intercambio de datos estándar para las API REST. Por lo tanto, es posible que necesite un conjunto diferente de bibliotecas para consumir y producir datos estructurados según la API REST con la que se esté comunicando. Sin embargo, JSON es muy popular y está disponible a menudo.

Extensibilidad

SOAP y REST son extensibles pero de formas muy diferentes. Vamos a sumergirnos en la comparación.

Comparación positiva

JABÓN El enlace de protocolo no tiene que ser HTTP, pero puede ser cualquier cosa. Los mensajes SOAP se pueden enviar a través de algunos otros protocolos basados ​​en TCP como SMTP o se pueden enviar a través del socket UDP como se hace en WS-Discovery y UPnP. El marco de Microsoft .NET WCF SOAP tiene TCP y transportes de canalización con nombre. Interfaces controladas por eventos o de cola de mensajes como JMS (Java Message Service) o AMQP (Protocolo de cola de mensajes avanzado) también se utilizan para SOAP.

SOAP también permite diferentes patrones de intercambio de mensajes. No tiene que ser solicitud-respuesta. Puede ser asincrónico, unidireccional o disparar y olvidar. SOAP se utiliza en la arquitectura orientada a servicios (SOA) donde los servicios están acoplados, empujando o reaccionando libremente a los mensajes enrutados por un bus de servicio empresarial (ESB).

RESTO Las API REST son extensibles en el sentido de que potencialmente pueden representar recursos con diferentes formatos de mensajes. A diferencia de SOAP, no está restringido a representaciones basadas en XML. Se pueden agregar nuevos recursos sin afectar los recursos existentes. Las API REST se pueden versionar incluyendo algún número de versión o identificador de versión como parte del URI.

Comparación crítica

JABÓN Con una mayor extensibilidad viene una mayor complejidad. No existe una forma única de implementar la mensajería SOAP, dados los diversos protocolos, patrones de mensajería y especificaciones WS- * que se pueden aplicar.
RESTO Las API REST generalmente están restringidas a HTTP, donde el método y el URI de recurso se envían en el encabezado de la solicitud HTTP. Sin embargo, los enfoques RESTful se han logrado con otras tecnologías como Protocolo de aplicación restringida (CoAP), que es una implementación de REST para entornos restringidos para aplicaciones Iot (Internet de las cosas). Los principios RESTful también se pueden seguir en agentes de mensajería como RabbitMQ y  MQTT, donde el identificador de recursos y la operación CRUD podrían potencialmente mapearse a destinos de mensajes o "temas".

Interoperabilidad

SOAP se diseñó teniendo en cuenta la interoperabilidad, siguiendo estándares abiertos, sin estar ligado a ninguna implementación, plataforma o lenguaje de programación específicos. Sin embargo, algunas cosas de la especificación se dejaron abiertas a interpretación. Algunas partes pueden ser confusas o tener errores o errores tipográficos o malos ejemplos. Los problemas surgen de cosas simples como si:

  • Se supone que un valor particular debe estar entre comillas o no.
  • Ciertas construcciones XML están bien o deben evitarse.
  • Se deben permitir o restringir tipos específicos de cosas en el cuerpo de SOAP.

Otro organismo de normalización, el Organización de interoperabilidad de servicios web (WS-I), surgió para proporcionar pautas para la interoperabilidad de servicios web. El WS-I proporciona varios perfiles de interoperabilidad. Cada perfil tiene una lista de requisitos y una lista de afirmaciones, que definen cómo verificar los requisitos. En resumen, los perfiles WS-I dicen cosas como "deberías hacer esto" y "no deberías hacer aquello". Dato curioso: Parasoft contribuyó al documento de afirmaciones de prueba (TAD) de WS-I Basic Profile 1.1.

Las API REST son interoperables en el sentido de que son fáciles de invocar. Hay muchas herramientas y API que pueden realizar solicitudes HTTP. Las herramientas populares incluyen cURL y  Cartero. Incluso se puede utilizar un formulario simple en una página web para realizar solicitudes HTTP. También hay varios estándares abiertos que se utilizan normalmente para las API REST además de HTTP, incluidos los formatos de mensajes abiertos como JSON. Las API REST también pueden implementar varios estándares abiertos de seguridad y autorización (más sobre esto más adelante).

Comparación positiva

JABÓN SOAP se diseñó teniendo en cuenta la interoperabilidad. Las especificaciones SOAP de W3C son creadas principalmente por Microsoft, que tiene su propia pila SOAP que se implementa como parte de .NET Framework de Microsoft, originalmente .NET Web Service Enhancements (WSE) y más tarde .NET Windows Communication Foundation (WCF). Sin embargo, las pilas de SOAP están disponibles en muchos otros proveedores, incluidos proyectos de código abierto como el proyecto Apache. Además de .NET, las pilas SOAP también están disponibles para diferentes plataformas y lenguajes de programación como java, python y mecanografiado. Los clientes SOAP y los servicios SOAP implementados con diferentes pilas SOAP son capaces de comunicarse si siguen el mismo conjunto de estándares SOAP abiertos.
RESTO Las API REST siguen el principio KISS (“manténgalo simple, estúpido”), siguiendo los principios generales de diseño de la arquitectura de software REST. Al ser fáciles de invocar, las API REST no requieren necesariamente una pila de software compleja como la que normalmente necesita para comunicarse con los puntos finales SOAP.

Comparación crítica

JABÓN SOAP tiene una gran cantidad de extensiones a las que a menudo se hace referencia como WS- *. Hay WS-Addressing, WS-Policy, WS-Discovery, WS-MetadataExchange, WS-SecureConversation, WS-SecurityPolicy, WS-Trust, WS-Federation. También existe WS-Security con varias especificaciones relacionadas, incluidas las relacionadas con la firma XML y SOAP, el cifrado XML y SOAP y SAML (Security Assertion Markup Language). La lista sigue y sigue y sigue. Es probable que un servicio SOAP siga varias especificaciones WS- *, lo que agrega complejidad a lo que originalmente se definió como un protocolo "simple". Su cliente debe seguir los mismos estándares WS- * que el servicio, o no podrá comunicarse correctamente.
RESTO Las API REST no necesariamente tienen que seguir estándares abiertos. Aunque JSON es muy popular, no existe un formato de intercambio de datos estándar. Cualquier tipo de contenido es una posibilidad, incluidos posiblemente los formatos de datos propietarios. Además, ciertos marcos de seguridad o autorización pueden introducir una complejidad adicional, lo que requiere una implementación compatible en el lado del cliente.

Seguridad

La seguridad es una consideración importante tanto para SOAP como para REST. La seguridad de la capa de transporte es necesaria para cifrar los mensajes a medida que se envían por cable para evitar escuchas. La seguridad de la capa de mensajes es necesaria para la seguridad de extremo a extremo, por lo que el mensaje está protegido de cualquier intermediario que pueda tener acceso a él antes de llegar a su destino previsto. Se necesitan mecanismos de autenticación o autorización para establecer la identidad entre cliente y servidor.

Comparación positiva

JABÓN SOAP tiene una gran colección de especificaciones de seguridad conocidas como WS-Security, publicadas por el organismo de estándares OASIS. Además de los mecanismos de seguridad de la capa de transporte como HTTPS, las especificaciones de WS-Security describen cómo incrustar la seguridad directamente dentro de los propios mensajes SOAP (incluidas firmas, datos cifrados) y cómo empaquetar tokens de seguridad para establecer una identidad como SAML (Security Assertion Markup Language).
RESTO REST puede aprovechar los mecanismos existentes en HTTP para la seguridad, incluidos los esquemas de autenticación basados ​​en SSL y HTTP. También existen estándares abiertos para la autorización que incluyen Conexión OpenID (OIDC), que se basa en OAuth y algunas otras especificaciones abiertas como Token web JSON (JWT).

Comparación crítica

JABÓN Las especificaciones de OASIS WS-Security son complejas. Los servicios que implementan múltiples WS-Security y otras especificaciones WS- * plantean desafíos para los clientes de construcción. ¿Qué almacenes de claves necesito? ¿Necesito firmar el mensaje o cifrarlo también? ¿Qué algoritmo de canonicalización XML se supone que debo usar? ¿Necesito primero obtener un token SAML e incluirlo en un encabezado SOAP? ¿Qué partes del mensaje necesito firmar y cifrar?
RESTO La seguridad de la capa de mensajes no es estándar, algunos son propietarios. Por ejemplo, Amazon AWS proporciona mecanismos del lado del servidor y del lado del cliente para cifrar los mensajes enviados hacia o desde sus API.

Definiciones de servicios

Hay varios tipos de formatos de documentación de consumibles de máquina para servicios SOAP y REST. Los documentos de definición de servicios permiten el procesamiento automatizado, como la generación de código automatizado para clientes o resguardos de servicio. Los documentos de definición de servicios también se pueden traducir a un formato de documentación amigable para el ser humano como una página web.

Comparación positiva

JABÓN Los servicios SOAP son descritos por WSDL, otra especificación abierta del W3C. Un WSDL es un documento XML. Define los puntos finales del servicio, las operaciones y los esquemas XML para los mensajes de solicitud, respuesta y error.
RESTO Hay varios formatos de definición de servicios para las API REST. Éstos incluyen OpenAPIRAMLPlano de APIWADL. Todos proporcionan diferentes formas de describir cosas comunes a las API REST como rutas de recursos, parámetros, operaciones y tipo y formato o esquema de representaciones. OpenAPI se basa en Esquema JSON especificaciones y se puede representar como JSON o YAML. Los documentos RAML se basan en Ñame y admite tanto el esquema JSON como el esquema XML (XSD). API Blueprint se basa en Markdown Syntax for Object Notation (MSON) con soporte para JSON Schema. WADL es un envío de W3C, basado en XML con soporte para describir representaciones XML usando XML Schema, un poco análogo a WSDL para SOAP.

Comparación crítica

JABÓN La especificación WSDL tiene algunos problemas con aclaraciones adicionales y recomendaciones de interoperabilidad proporcionadas por la Organización de interoperabilidad de servicios web (WS-I). También hay varias versiones de WSDL. WSDL 1.1 se implementa con mayor frecuencia. WSDL 2.0, anteriormente conocido como WSDL 1.2, no fue adoptado por todas las pilas SOAP, incluido el WCF .NET de Microsoft. Curiosamente, WSDL 2.0 introdujo soporte para describir API REST.
RESTO No existe un formato de definición de servicio estándar para las API REST. Sin embargo, OpenAPI es una consideración cercana por ser el estándar. OpenAPI fue desarrollado originalmente por SmartBear como "Swagger", luego donado a la Fundación Linux como OpenAPI. La especificación es supervisada por el Iniciativa OpenAPI, que incluye miembros de una colección diversa de grandes corporaciones, incluidas Google, IBM y Microsoft.

Cada formato de definición de servicio tiene su propia colección de herramientas para la generación de códigos y documentos. Esto significa que debe utilizar un conjunto diferente de herramientas según la implementación del servicio. Sin embargo, existen convertidores para que pueda convertir un documento OpenAPI en una RAML (o viceversa).

¿Cómo se supone que debo probar todo esto? 😵

REST y SOAP ofrecen sus propias compensaciones y desafíos, especialmente con respecto a las pruebas. Para probar una API, debe poder crear clientes, enviar datos de entrada y luego poder ver y validar la salida que se devolvió.

Comparación positiva

JABÓN Un documento WSDL puede proporcionar una descripción completa de un servicio SOAP, incluidos sus requisitos de seguridad. Hay varias herramientas comerciales y de código abierto disponibles que pueden consumir documentos WSDL para producir automáticamente clientes para probar terminales SOAP. Un ejemplo sencillo es el de Microsoft Cliente de prueba WCF .
RESTO Las API REST también pueden proporcionar un documento de definición de servicio, que se puede consumir para producir clientes de prueba. Para OpenAPI, IU de Swagger proporciona una interfaz web sencilla para "probar" cada una de las operaciones expuestas por la API.

Comparación crítica

JABÓN Los servicios SOAP pueden implementarse utilizando protocolos distintos a HTTP, donde la comunicación puede requerir una interfaz de mensajería específica como JMS. Varios protocolos WS- * son complejos. Las herramientas gratuitas y de código abierto tienen limitaciones y carecen de soporte para todos los protocolos de transporte y WS- *. Sin embargo, Parasoft SOAtest ayuda a resolver esto, ya que tiene un soporte completo para SOAP y protocolos relacionados.
RESTO Los servicios REST no necesariamente tienen definiciones de servicio. La creación manual de clientes puede ser difícil y tediosa, ya que se determina la secuencia correcta de llamadas a la API para encadenarlas para crear los escenarios deseados. Sin embargo, Parasoft SOAtest ayuda a resolver esto. Además de poder crear clientes de prueba a partir de varios formatos de definición de servicios, SOAtest's Generador de pruebas de API inteligente automatiza la creación de pruebas de API mediante el seguimiento de las llamadas a la API y el uso de inteligencia artificial para construir y configurar automáticamente escenarios de prueba.

¿Todavía te da vueltas la cabeza? Deje que Parasoft le ayude. Reduzca el costo, el tiempo y la complejidad de las interfaces de servicio de prueba con la solución completa de prueba de API de extremo a extremo, Parasoft SOAtest. Ya sea SOAP, REST u otras interfaces o tecnologías de servicio, SOAtest lo tiene cubierto. Solicite una demostración hoy!

¿Mirando más allá de SOAP y REST? Consulte nuestro documento técnico sobre pruebas de microservicios para obtener más información sobre los enfoques modernos de arquitecturas orientadas a servicios y prueba de microservicios.

Prueba de microservicios: obtenga el documento técnico

Escrito por

Joseph Benken

Joseph es ingeniero de software senior en Parasoft. Ha ayudado a desarrollar muchas funciones y tecnologías centrales utilizadas en varios productos, incluidos SOAtest, Virtualize y Selenic. Ha estado con Parasoft desde 2006.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft