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

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. El Protocolo simple de acceso a objetos es un protocolo orientado a objetos mediante el cual los objetos se intercambian entre el cliente y el servidor, se serializan 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 en la especificación SOAP o la amplían, 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" generalmente 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.

DESCANSAR. 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 compatible con REST o API web 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 recurso 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 adoptar 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í.

omnicanal

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

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.

operaciones REST ofrecer un mayor grado de sencillez. Se utiliza un URI para identificar el recurso, desvinculado 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 en función del estado de la conversación entre el cliente y el extremo del servicio.

Comparación crítica

Servicios SOAP puede tener una complejidad mucho mayor al admitir operaciones arbitrarias y al rastrear potencialmente el estado. Un ejemplo podría ser un servicio de librería que tenga una operación "addToCart". Cada vez que un cliente llama a "addToCart", el servicio rastrea el artículo en el carrito de compras del cliente. Un cliente diferente puede llamar a "addToCart" y no afectar el carrito de compras de otro cliente. El servicio rastrea el estado de cada cliente por separado.

API REST están más restringidos 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 saber el ID de su carrito para que pueda 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

mensajería SOAP implica el intercambio de documentos XML llamados sobres SOAP. Un sobre SOAP contiene un elemento "Cuerpo" y un elemento "Encabezado" opcional. El XML dentro del elemento "Cuerpo" puede ser arbitrario, pero generalmente representa una o más entidades u objetos. El tipo de contenido es "texto/xml" o "aplicación/soap+xml", dependiendo de si se sigue 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 datos binarios de manera eficiente en mensajes XML y SOAP como MIME "Multipart/Related", evitando la necesidad de codificar en base64 los datos binarios directamente dentro de las etiquetas XML.

Mensajería de API REST implica el intercambio de representaciones de un recurso. Una "representación" podría 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".

DESCANSAR. 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.

DESCANSAR. 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).

DESCANSAR. 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.

DESCANSAR. 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 fue diseñado con la interoperabilidad en mente. Las especificaciones W3C SOAP 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 SOAP están disponibles a través de 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 TypeScript. 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 siguen el principio KISS ("mantenerlo simple, estúpido"), siguiendo los principios generales de diseño de la arquitectura de software REST. Al ser simples de invocar, las API REST no requieren necesariamente una pila de software compleja como la que normalmente necesita para comunicarse con los puntos finales de SOAP.

Comparación crítica

JABÓN tiene una miríada 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 (lenguaje de marcado de aserción de seguridad). La lista sigue y sigue y sigue. Lo más probable es 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 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 patentados. Además, ciertos marcos de seguridad o autorización pueden presentar 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 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 puede aprovechar los mecanismos existentes en HTTP para la seguridad, incluidos los esquemas de autenticación basados ​​en SSL y HTTP. También hay 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?

DESCANSAR. 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.

DESCANSAR. Hay varios formatos de definición de servicios para las API REST. Éstos incluyen OpenAPI, RAML, Plano de API y WADL. 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.

DESCANSAR. 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 .

DESCANSAR. 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

Servicios SOAP puede implementarse utilizando protocolos distintos de 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 falta de soporte para todos los protocolos de transporte y WS-*. Sin embargo, Parasoft SOAtest ayuda a resolver esto, con soporte completo para SOAP y protocolos relacionados.

Servicios REST no necesariamente tienen definiciones de servicio. La creación manual de clientes puede ser difícil y tediosa, ya que determina la secuencia correcta de llamadas a la API para unirlas y crear los escenarios deseados. Sin embargo, Prueba SOA de Parasoft 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.

¿Ya 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.