SOAP no ha desaparecido. Los sistemas bancarios, las pasarelas de pago, los servicios gubernamentales y las plataformas empresariales más antiguas aún exponen puntos finales SOAP, y alguien tiene que probarlos. Si has pasado tu carrera en REST y JSON, un servicio SOAP puede sentirse extraño. El protocolo es más estricto, las cargas útiles son XML, y el contrato reside en un archivo WSDL separado.
La buena noticia es que probar una API SOAP en línea no es difícil una vez que entiendes lo que realmente quiere de ti. Esta guía explica cómo las pruebas SOAP difieren de las pruebas REST, recorre una solicitud real y cubre las herramientas en línea que manejan SOAP sin problemas.
Por qué las pruebas SOAP son diferentes
REST es un estilo. SOAP es un protocolo con reglas. Esa distinción da forma a todo lo relacionado con cómo lo pruebas.
Un mensaje SOAP es siempre un documento XML envuelto en un sobre. El sobre tiene una cabecera para metadatos como la autenticación o el enrutamiento, y un cuerpo que contiene la operación real y sus parámetros. No puedes simplemente enviar un objeto JSON suelto. La estructura es obligatoria, y un sobre mal formado es rechazado antes de que tu lógica se ejecute. SOAP también casi siempre viaja sobre HTTP POST, incluso para operaciones que solo leen datos, y espera un Content-Type específico, generalmente text/xml o application/soap+xml.
La mayor diferencia práctica es el WSDL. Un WSDL, o archivo de Lenguaje de Descripción de Servicios Web, es un contrato legible por máquina que enumera cada operación que ofrece el servicio, la forma exacta de cada solicitud y respuesta, y la dirección del punto final. REST rara vez envía algo tan estricto. Cuando pruebas SOAP, el WSDL es tu mapa. Un buen probador SOAP en línea lee el WSDL y genera plantillas de solicitud para ti, de modo que no estás escribiendo sobres a mano de memoria. Si quieres una imagen más amplia del contrato, nuestras notas sobre pruebas de contratos API explican por qué un contrato estricto es un activo.
Cómo se ve realmente una solicitud SOAP
Aquí hay una solicitud SOAP realista contra un servicio de conversión de divisas. Observa el sobre, las declaraciones de espacio de nombres y la operación anidada en el cuerpo.
POST /CurrencyService.asmx HTTP/1.1
Host: rates.example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "https://rates.example.com/ConvertAmount"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cur="https://rates.example.com/">
<soap:Header>
<cur:AuthToken>e9f2a1c7-4b8d-4c2a-9f31-7d6e5a4b3c21</cur:AuthToken>
</soap:Header>
<soap:Body>
<cur:ConvertAmount>
<cur:FromCurrency>USD</cur:FromCurrency>
<cur:ToCurrency>EUR</cur:ToCurrency>
<cur:Amount>250.00</cur:Amount>
</cur:ConvertAmount>
</soap:Body>
</soap:Envelope>
La respuesta llega envuelta de la misma manera:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cur="https://rates.example.com/">
<soap:Body>
<cur:ConvertAmountResponse>
<cur:ConvertAmountResult>231.45</cur:ConvertAmountResult>
</cur:ConvertAmountResponse>
</soap:Body>
</soap:Envelope>
Dos detalles suelen confundir a la gente. El encabezado HTTP SOAPAction es requerido por muchos servicios y debe coincidir con la operación, o se obtiene un fallo. Y cuando algo falla, SOAP no devuelve un HTTP 400 con un mensaje claro. Devuelve un HTTP 200 con un elemento <soap:Fault> dentro del cuerpo. Tu prueba tiene que analizar el cuerpo para saber si la llamada tuvo éxito realmente. Comprobar solo el código de estado no es suficiente, lo cual es una de las razones por las que las afirmaciones API estructuradas importan más aquí que en REST.
Herramientas en línea para probar APIs SOAP
Apidog
Apidog maneja SOAP junto con REST, GraphQL y WebSocket en un solo lugar. Importas un WSDL y genera la estructura de la solicitud para que no tengas que construir sobres a mano. Puedes añadir afirmaciones sobre elementos XML, encadenar solicitudes en un escenario y ejecutar todo como un conjunto automatizado. Dado que también diseña y simula APIs, puedes simular una respuesta SOAP antes de que el servicio real esté listo. Descarga Apidog para probar servicios SOAP en el nivel gratuito.
SoapUI
SoapUI es la herramienta original de prueba SOAP y sigue siendo la más completa. Apúntala a un WSDL y construye un proyecto con cada operación. La edición de código abierto es gratuita y robusta para pruebas SOAP funcionales y basadas en datos. Es una aplicación de escritorio Java más pesada, y las características de informes más pulidas se encuentran en el nivel de pago ReadyAPI. Para una mirada más cercana, consulta qué es SoapUI y cómo funciona.
Postman
Postman puede enviar solicitudes SOAP. Configuras el cuerpo como XML puro, añades los encabezados Content-Type y SOAPAction manualmente y pegas tu sobre. Funciona, pero Postman no analiza un WSDL, por lo que construyes los sobres tú mismo. Está bien para una verificación puntual y es menos cómodo para una gran superficie SOAP.
Probadores SOAP basados en navegador
Varias herramientas web ligeras te permiten pegar una URL WSDL y disparar solicitudes desde una pestaña del navegador. Son útiles para una verificación rápida sin tener que instalar nada. Los límites aparecen rápidamente: soporte de afirmaciones deficiente, poca o ninguna automatización, y ninguna forma de organizar un conjunto de pruebas real. Úsalas para confirmar que un punto final está activo, no para construir un conjunto de regresión.
Un flujo de trabajo rápido para pruebas SOAP
- Obtén el WSDL. La mayoría de los servicios SOAP lo exponen añadiendo
?wsdla la URL del punto final. Ábrelo y confirma que carga. - Importa el WSDL a tu herramienta. Apidog y SoapUI generan plantillas de solicitud a partir de él. Este es el mayor ahorro de tiempo.
- Completa los parámetros de la operación. Usa valores reales. Prueba una conversión de moneda con una cantidad real y códigos de moneda válidos.
- Establece los encabezados. Confirma
Content-Typey, cuando sea necesario,SOAPAction. UnSOAPActionfaltante es la causa más común de un fallo inexplicable. - Envía e inspecciona el cuerpo. No te detengas en el estado HTTP. Abre el cuerpo de la respuesta y busca
<soap:Fault>. - Añade afirmaciones. Afirma que un elemento específico existe y contiene el valor esperado. Luego encadena una llamada de seguimiento si tu flujo lo necesita.
Para organizar esto en un conjunto mantenible, nuestra guía sobre construcción de suites de prueba para la automatización de API se aplica directamente al trabajo con SOAP.
Fallos SOAP y cómo hacer afirmaciones sobre ellos
Un fallo SOAP es la estructura de error del protocolo. Contiene un faultcode, un faultstring y, a veces, un elemento detail. Debido a que llega con un HTTP 200, una prueba que solo verifica el estado pasará una llamada fallida. Esto es un falso positivo silencioso y peligroso.
Escribe tus afirmaciones SOAP para mirar dentro del cuerpo. Afirma que no hay ningún elemento <soap:Fault> presente en una ruta de éxito. En una ruta de error deliberada, afirma lo contrario, que el fallo aparece y el faultcode coincide con lo que esperas. Probar los casos de fallo es tan importante como la ruta feliz, porque los servicios SOAP a menudo codifican reglas de negocio, como una transacción denegada, como fallos en lugar de datos. La documentación de fallos SOAP del W3C describe la estructura si necesitas el detalle formal.
WS-Security añade otra capa. Muchos servicios SOAP empresariales esperan un encabezado de seguridad firmado o con un token. Si tus solicitudes fallan con un error de autenticación, el WSDL o la documentación del servicio indicarán qué perfil de seguridad está en juego. Herramientas como SoapUI y Apidog te permiten configurar estos encabezados en lugar de escribir el XML a mano.
Leer un WSDL sin perderse
Un archivo WSDL parece intimidante la primera vez que lo abres. Es un XML largo, profundamente anidado, y la mayor parte es de fontanería de máquina. No necesitas leerlo todo. Cuatro partes contienen la información que realmente quieres.
La sección types define las estructuras de datos, generalmente como Esquema XML, así que aquí es donde aprendes la forma y las restricciones exactas de cada parámetro. Los elementos message describen la entrada y salida para cada operación. El portType enumera las operaciones mismas, que son las llamadas que puedes hacer. Las secciones service y binding proporcionan la dirección del punto final concreto y los detalles de transporte. Cuando importas un WSDL a una herramienta, esta lee las cuatro y las convierte en solicitudes listas para editar, por lo que importar siempre supera a la escritura manual.
Un detalle que vale la pena saber: un WSDL puede dividirse en varios archivos usando declaraciones de import, a menudo extrayendo esquemas de ubicaciones separadas. Si tu herramienta reporta un tipo faltante, probablemente un archivo referenciado no se pudo resolver. Asegúrate de que cada URL importada sea accesible desde donde se ejecuta tu herramienta. Este tipo de dependencia de contrato es exactamente la razón por la que los equipos tratan el WSDL como un artefacto versionado en lugar de algo que solo vive en un servidor.
Pruebas SOAP basadas en datos
Los servicios SOAP a menudo tienen reglas de negocio estrictas, y una sola solicitud de "ruta feliz" rara vez demuestra mucho. Un servicio de moneda debe probarse con pares válidos, con una moneda no soportada, con una cantidad de cero y con una cantidad negativa. Un servicio de pago debe probarse con una tarjeta aprobada, una tarjeta rechazada y una caducada. Escribir cada uno de estos a mano es lento y fácil de equivocarse.
Las pruebas basadas en datos resuelven esto. Escribes la solicitud una vez con marcadores de posición, luego le proporcionas una tabla de filas de entrada y resultados esperados. La herramienta ejecuta la solicitud para cada fila y verifica cada resultado. SoapUI ha soportado este patrón durante años, y Apidog lo soporta a través de su ejecutor de escenarios. La recompensa es una cobertura real de los casos límite que los servicios SOAP tienden a codificar como fallos. Para el patrón más amplio, nuestra guía sobre pruebas API basadas en datos con CSV y JSON explica cómo estructurar los datos de entrada, y se aplica a SOAP al igual que a REST.
Preguntas frecuentes
¿Cuál es la diferencia entre las pruebas SOAP y REST?
Las pruebas SOAP funcionan con un protocolo XML estricto con un contrato WSDL, sobres obligatorios y fallos devueltos dentro de un cuerpo HTTP 200. Las pruebas REST suelen tratar con JSON, convenciones más flexibles y códigos de estado HTTP significativos. Una prueba SOAP debe analizar el cuerpo de la respuesta para confirmar el éxito; una prueba REST a menudo puede confiar en el código de estado.
¿Necesito el WSDL para probar una API SOAP?
Puedes enviar una solicitud SOAP sin él si ya conoces la estructura exacta del sobre. Pero el WSDL facilita mucho las pruebas porque las herramientas generan plantillas de solicitud correctas a partir de él. La mayoría de los servicios exponen el WSDL añadiendo ?wsdl a la URL del punto final. Siempre empieza por ahí.
¿Por qué mi solicitud SOAP devuelve un error aunque el estado es 200?
SOAP reporta errores como un elemento <soap:Fault> dentro del cuerpo, no como un código de error HTTP, por lo que un 200 con un error es normal. Las causas usuales son un encabezado SOAPAction faltante o incorrecto, un sobre mal formado, una falta de coincidencia de espacio de nombres o una falla en la comprobación de seguridad. Lee el faultstring para conocer la razón específica.
¿Puedo probar APIs SOAP en línea de forma gratuita?
Sí. Apidog soporta SOAP en su nivel gratuito e importa archivos WSDL, y la edición de código abierto de SoapUI está diseñada para SOAP. También existen probadores web ligeros para comprobaciones rápidas, aunque carecen de soporte real para afirmaciones y automatización.
¿Cómo automatizo las pruebas de API SOAP?
Importa el WSDL, construye un escenario que encadene las operaciones en orden, añade afirmaciones sobre los elementos de respuesta y la ausencia de fallos, y luego ejecútalo desde el ejecutor de una herramienta o en tu pipeline de CI. Tanto SoapUI como Apidog soportan suites SOAP programadas y activadas por pipeline, por lo que una ejecución de regresión SOAP se ajusta al mismo flujo de automatización que REST.