Cómo Probar Servicios Web SOAP y WSDL en Apidog

Se te ha entregado un endpoint SOAP. Puede ser un conversor de moneda heredado del que aún depende tu equipo de facturación, o un servicio web de pedidos que un socio ejecuta en .NET. Necesitas llamarlo, comprobar que devuelve lo que promete el contrato y verificar que sigue funcionando mientras cambia el código a su alrededor. Las herramientas REST no encajan del todo: SOAP requiere un sobre XML completo, un Content-Type específico y un WSDL que describe cada operación.

Prueba Apidog hoy

Apidog admite solicitudes SOAP y WebService junto con REST, GraphQL y gRPC, por lo que no necesitas una aplicación independiente para un único servicio heredado. Esta guía cubre dos rutas:

1. Enviar una solicitud SOAP manualmente.
2. Importar un WSDL para que Apidog cree el entorno y los endpoints.

Para una visión general del protocolo, consulta la comparación de REST, GraphQL, gRPC y SOAP. Para la definición formal de la estructura del sobre, revisa la especificación SOAP del W3C.

Qué es SOAP y por qué necesita un manejo diferente

SOAP (Simple Object Access Protocol) es un protocolo de comunicación basado en XML que permite integrar plataformas y lenguajes distintos. Por ejemplo, un cliente Java puede comunicarse con un servicio .NET mediante el mismo contrato, sin depender de la implementación interna del otro sistema.

Al probar SOAP, hay tres propiedades clave:

• Los mensajes usan XML. Cada solicitud y respuesta es un documento estructurado, no un JSON libre. Si necesitas repasar XML, consulta la referencia de XML de MDN.
• Generalmente usa HTTP o HTTPS. Aunque SOAP admite otros transportes, HTTP/HTTPS es el caso más habitual.
• El contrato es estricto. El sobre, los espacios de nombres, las operaciones y los parámetros deben respetar la definición del servicio.

Esta rigidez explica por qué SOAP sigue presente en integraciones multiplataforma, sistemas heredados y transacciones seguras con WS-Security. No puedes enviar una solicitud REST convencional a un endpoint SOAP: necesitas la cabecera correcta, un cuerpo XML envuelto en un sobre SOAP y una forma de validar el XML de respuesta.

Para profundizar en la estructura de los sobres, consulta esta guía sobre APIs SOAP y XML.

Antes de empezar

Para enviar solicitudes SOAP o WebService, necesitas Apidog versión 2.1.31 o superior. Las versiones anteriores no soportan estas solicitudes.

Antes de continuar:

1. Abre Apidog.
2. Comprueba la versión instalada.
3. Actualiza si usas una versión anterior a la 2.1.31.
4. Reúne los datos del servicio:
   • URL del endpoint.
   • Nombre de la operación.
   • Parámetros requeridos.
   • Archivo WSDL, si está disponible.

Si tienes un WSDL, mantenlo a mano: la segunda ruta de esta guía lo importa directamente. Consulta también la especificación de WSDL.

Ruta A: enviar una solicitud SOAP manualmente

Usa esta ruta cuando ya tienes la URL del endpoint y conoces la operación que necesitas invocar.

Paso 1: configurar Content-Type

SOAP no infiere automáticamente la cabecera de contenido. Añade Content-Type en la sección de cabeceras de la solicitud.

Los valores habituales son:

Content-Type: text/xml; charset=utf-8

o:

Content-Type: application/soap+xml

Como regla práctica:

• SOAP 1.1 suele usar text/xml; charset=utf-8.
• SOAP 1.2 suele usar application/soap+xml.

Si no sabes cuál usar, revisa el WSDL o la documentación del servicio. Si recibes un error relacionado con el tipo de contenido, prueba el otro valor.

Paso 2: establecer el cuerpo como XML y añadir el sobre SOAP

Configura el formato del cuerpo de la solicitud como xml. Después, pega el sobre SOAP completo.

Este ejemplo llama a la operación pública NumberToWords, que convierte un número en texto:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:web="http://www.dataaccess.com/webservicesserver/">
  <soap:Body>
    <web:NumberToWords>
      <web:ubiNum>1234</web:ubiNum>
    </web:NumberToWords>
  </soap:Body>
</soap:Envelope>

Puntos que debes validar antes de enviar:

• El espacio de nombres de la operación debe coincidir con el definido por el servicio.
• soap:Body envuelve la llamada real.
• web:NumberToWords es la operación.
• web:ubiNum es el parámetro de entrada.

No adivines los espacios de nombres: cópialos del WSDL o de la documentación del servicio.

Paso 3: enviar y validar la respuesta XML

Envía la solicitud. La respuesta llegará como otro sobre SOAP.

Para el ejemplo anterior, la respuesta incluye NumberToWordsResponse y el resultado de la operación:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <m:NumberToWordsResponse xmlns:m="http://www.dataaccess.com/webservicesserver/">
      <m:NumberToWordsResult>one thousand two hundred and thirty four</m:NumberToWordsResult>
    </m:NumberToWordsResponse>
  </soap:Body>
</soap:Envelope>

Valida al menos estos elementos:

1. El sobre SOAP llegó correctamente.
2. Existe el nodo de respuesta esperado, por ejemplo NumberToWordsResponse.
3. El nodo de resultado contiene el valor previsto.

La documentación de WebService de Apidog en webservice.apidog.io incluye más ejemplos de configuración y sobres SOAP.

En un servicio real, el patrón no cambia. Por ejemplo:

• Para ConvertCurrency, envía fromCurrency, toCurrency y amount.
• Para GetOrderStatus, envía orderId.
• Lee el resultado desde el nodo correspondiente de la respuesta.

La secuencia siempre es la misma: configurar cabeceras, construir XML, enviar y validar el sobre de respuesta.

Ruta B: importar un WSDL para generar los endpoints

Escribir sobres manualmente funciona para una operación aislada. Cuando el servicio expone muchas operaciones, importa el WSDL para que Apidog analice el contrato y cree los endpoints.

Un WSDL describe las operaciones disponibles, sus entradas y la dirección del servicio.

Importar el archivo

Sigue esta ruta en Apidog:

1. Ve a Configuración.
2. Selecciona Importar Datos.
3. Elige WSDL.
4. Sube un archivo .wsdl o .xml.
5. Revisa la vista previa de los endpoints detectados.
6. Abre la pestaña Environments.
7. Verifica la dirección del servicio.
8. Haz clic en Confirmar.
9. Selecciona el entorno importado desde la esquina superior derecha.
10. Envía una solicitud.

Verificar la URL del servicio antes de confirmar

El paso más importante es revisar la dirección del servicio en Environments.

El WSDL puede apuntar a:

• Un host de staging.
• Un endpoint obsoleto.
• Una URL de marcador de posición.
• Un entorno diferente al que quieres probar.

Corrige la dirección antes de hacer clic en Confirmar. De lo contrario, las solicitudes importadas se enviarán al servidor equivocado.

Seleccionar el entorno importado

La URL Base se almacena en el entorno creado durante la importación.

Antes de enviar una solicitud:

1. Abre el selector de entorno en la esquina superior derecha.
2. Selecciona el entorno importado.
3. Envía la solicitud.

Si no seleccionas ese entorno, la URL Base no se aplicará y la solicitud puede fallar.

Una vez importado el WSDL, cada operación aparece como un endpoint invocable. Puedes validar las respuestas XML igual que en la Ruta A, sin escribir cada sobre desde cero.

Si estás migrando un proyecto completo, consulta la guía para importar proyectos SOAP.

La importación documentada admite archivos .wsdl y .xml. La importación desde una URL o pegando el contenido del WSDL no está documentada, así que utiliza la carga de archivos.

Viniendo de SoapUI

Si tus pruebas SOAP están en SoapUI, no necesitas reconstruirlas manualmente.

Flujo recomendado:

1. Exporta o conserva el WSDL de tu servicio.
2. Impórtalo en Apidog mediante la Ruta B.
3. Revisa los endpoints generados.
4. Verifica el entorno y la URL Base.
5. Ejecuta y valida las operaciones importadas.

Esto permite mantener operaciones SOAP, endpoints REST y escenarios de prueba en un mismo espacio de trabajo. Consulta la comparación entre Apidog y SoapUI para conocer las diferencias de flujo de trabajo.

Afirmaciones y variaciones

Una solicitud exitosa confirma que el endpoint responde. Una prueba útil verifica que la respuesta cumple el contrato.

Después de recibir una respuesta SOAP, añade afirmaciones para comprobar:

• Que existe el nodo de respuesta esperado.
• Que el elemento de resultado está presente.
• Que el valor coincide con las reglas del contrato.

Ejemplos:

• En un servicio de moneda, valida que el importe convertido sea numérico y esté dentro de un rango esperado.
• En un servicio de pedidos, valida que el estado devuelto pertenezca a los valores permitidos.

Después, crea escenarios repetibles que encadenen operaciones. Por ejemplo:

1. Crear un pedido.
2. Guardar el identificador devuelto.
3. Consultar el estado usando ese identificador.
4. Validar el estado final.

La guía sobre cómo escribir un escenario de prueba con Apidog muestra cómo extraer valores de una respuesta y reutilizarlos en solicitudes posteriores. El patrón es independiente del protocolo, por lo que puedes combinar llamadas SOAP y REST en un mismo escenario.

Añadir WS-Security

Los servicios SOAP seguros suelen usar WS-Security para mensajes cifrados o autenticados.

En ese caso, añade el bloque wsse dentro de la cabecera del sobre SOAP:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
  <soap:Header>
    <wsse:Security>
      <!-- Bloque de seguridad requerido por el servicio -->
    </wsse:Security>
  </soap:Header>
  <soap:Body>
    <!-- Operación SOAP -->
  </soap:Body>
</soap:Envelope>

La mecánica no cambia:

1. Configura Content-Type.
2. Incluye el sobre completo, incluida la cabecera de seguridad, en el cuerpo XML.
3. Envía la solicitud.
4. Valida la respuesta.

Automatiza el flujo de trabajo con la CLI de Apidog

Cuando tus solicitudes SOAP o endpoints importados desde WSDL están guardados como escenarios de prueba, puedes usar la CLI de Apidog desde la línea de comandos.

Instálala con Node.js v16 o posterior:

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

Ejecuta un escenario guardado contra un entorno específico:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

Parámetros:

• -t: ID del escenario de prueba.
• -e: ID del entorno.
• -r: reportero, como cli, html o junit.

Puedes separar varios reporteros mediante comas.

La documentación confirma que la CLI ejecuta escenarios y suites de prueba guardados. Sin embargo, no especifica si los escenarios basados en pasos SOAP se ejecutan de forma desatendida. Úsala como ejecutor para los escenarios HTTP del proyecto y para mantener los endpoints importados desde WSDL sincronizados en CI, sin asumir una ejecución específica de SOAP.

Para conectarla a tu pipeline, consulta la guía de CI/CD de la CLI de Apidog.

Preguntas frecuentes

¿Qué Content-Type debo usar para una solicitud SOAP?

Usa uno de estos valores:

text/xml; charset=utf-8

application/soap+xml

SOAP 1.1 suele requerir el primero y SOAP 1.2 el segundo. Configúralo manualmente en las cabeceras de la solicitud. Si recibes un error de tipo de contenido, prueba el otro valor.

¿Necesito un plan de pago para probar SOAP en Apidog?

El requisito documentado es usar Apidog 2.1.31 o superior. No se documentan restricciones de suscripción o autoalojamiento específicas para el soporte de SOAP o WSDL.

¿Puedo importar un WSDL desde una URL?

La importación documentada acepta archivos .wsdl y .xml. La importación mediante URL o pegando el texto del WSDL no está documentada. Sube el archivo y selecciona el entorno creado antes de enviar solicitudes.

¿Cómo pruebo APIs SOAP y REST en el mismo proyecto?

Apidog permite trabajar con SOAP, REST, GraphQL y otros tipos de solicitud dentro del mismo espacio de trabajo. Puedes combinar operaciones SOAP con endpoints REST y encadenarlas en escenarios de prueba.

Si también trabajas con GraphQL, consulta la guía para probar APIs GraphQL en Apidog.

Mis solicitudes importadas de WSDL llegan al servidor equivocado. ¿Qué pasó?

Las causas más comunes son:

1. La dirección del servicio en Environments era incorrecta cuando importaste el WSDL.
2. No seleccionaste el entorno importado desde la esquina superior derecha.

Vuelve a importar el archivo si es necesario, revisa la dirección del servicio antes de confirmar y activa el entorno correcto antes de enviar.

Conclusión

Probar SOAP no requiere una herramienta independiente para sistemas heredados. Con Apidog, puedes:

• Enviar sobres SOAP manualmente.
• Configurar Content-Type.
• Definir el cuerpo como xml.
• Validar respuestas XML.
• Importar un WSDL para generar endpoints y entornos.
• Crear escenarios repetibles y automatizarlos desde la CLI.

Ambas rutas ofrecen el mismo resultado: una forma repetible de comprobar que un servicio web sigue cumpliendo su contrato.

Descarga Apidog en la versión 2.1.31 o superior, importa tu WSDL y aplica a tus servicios SOAP las mismas prácticas de prueba que usas para el resto de tu superficie API.