Se te ha entregado un endpoint SOAP. Tal vez sea un conversor de moneda heredado del que tu equipo de facturación aún depende, o un servicio web de gestión de pedidos que un socio ejecuta en .NET. Necesitas llamarlo, confirmar que devuelve lo que el contrato promete y demostrar que se mantiene correcto a medida que el código a su alrededor cambia. Las herramientas REST no encajan del todo, porque SOAP requiere un sobre XML completo, un Content-Type específico y un WSDL que describe cada operación.
Apidog maneja solicitudes SOAP y de WebService junto con REST, GraphQL y gRPC, por lo que no necesitas una aplicación separada para ese único servicio heredado en tu pila. Esta guía recorre ambas rutas documentadas: enviar una solicitud SOAP manualmente e importar un WSDL para que Apidog construya el entorno y los endpoints por ti. Si primero quieres una visión más amplia del protocolo, nuestra comparación de REST, GraphQL, gRPC y SOAP explica dónde cada uno de ellos encuentra su lugar. Para la definición formal de la estructura del sobre, la especificación SOAP del W3C es la fuente autorizada.
Qué es SOAP y por qué necesita un manejo diferente
Apidog describe SOAP como el Protocolo Simple de Acceso a Objetos (Simple Object Access Protocol), un protocolo de comunicación basado en XML que permite que diversas plataformas y lenguajes de programación se comuniquen entre sí. Esa única idea explica por qué tantas empresas aún lo utilizan. Un cliente Java y un servicio .NET pueden comunicarse a través del mismo contrato sin preocuparse por los detalles internos del otro.
Tres propiedades importan al probarlo. SOAP utiliza XML para el formato de mensajes, por lo que cada solicitud y respuesta es un documento estructurado, no un blob JSON suelto. Si el XML en sí es un territorio desconocido, la referencia de XML de MDN es una sólida introducción a la sintaxis que leerás y escribirás. Generalmente viaja a través de HTTP o HTTPS, aunque el protocolo soporta otros. Y sigue los estándares del W3C para una comunicación estructurada y confiable, por lo que la forma del mensaje es estricta y las reglas de validación son firmes.
Esa rigidez es la razón por la que los endpoints SOAP se mantienen en servicio para la integración multiplataforma, puentes de sistemas heredados a modernos y transacciones seguras utilizando WS-Security para mensajería cifrada y autenticada. También es la razón por la que no puedes simplemente enviar una solicitud de estilo REST a uno. Necesitas la cabecera correcta, un cuerpo XML envuelto en un sobre SOAP y una forma de leer el XML que regresa. Si quieres una mirada más profunda a cómo el sobre y su cuerpo transportan datos, consulta nuestro desglose de APIs SOAP y XML.
Antes de empezar
Un requisito indispensable rige todo lo que sigue. Para enviar una solicitud SOAP o WebService, Apidog debe ser la versión 2.1.31 o superior. Las versiones anteriores no lo soportan. Abre Apidog, verifica tu versión y actualiza si estás desactualizado. Todo lo demás en esta guía asume que estás en la versión 2.1.31 o posterior.
Si aún no tienes Apidog, descárgalo y sigue los pasos. Pruébalo gratis, no se requiere tarjeta de crédito.
También querrás tener a mano los detalles de tu servicio de destino: la URL del endpoint, el nombre de la operación que quieres llamar y sus parámetros. Si tienes un archivo WSDL, tenlo cerca, porque la segunda parte de esta guía lo importa directamente.
Ruta A: enviar una solicitud SOAP manualmente
Esta es la ruta cuando tienes un endpoint y conoces la operación que quieres llamar. Hay tres cosas que debes configurar que una solicitud REST no necesita, y hacerlas bien es todo el trabajo.
Paso 1: configurar la cabecera Content-Type manualmente
Las solicitudes SOAP no infieren su propia cabecera. Debes configurar el Content-Type tú mismo, y hay dos valores válidos:
text/xml; charset=utf-8application/soap+xml
Cuál es correcto depende del servicio. Los endpoints SOAP 1.1 suelen esperar text/xml; charset=utf-8, mientras que los endpoints SOAP 1.2 a menudo desean application/soap+xml. Si no estás seguro, consulta el WSDL o la documentación del servicio, y si el primer valor devuelve un error sobre el tipo de contenido, cambia al otro. Añade la cabecera en la sección de Cabeceras de la solicitud antes de enviarla.
Paso 2: establecer el formato del cuerpo a XML y pegar el sobre
Establece el formato del Cuerpo de la solicitud a xml, luego pega el sobre SOAP. El sobre es un documento con declaraciones de espacio de nombres y un elemento Body que contiene la operación que estás llamando, además de cualquier parámetro anidado dentro de él.
Aquí tienes un ejemplo práctico contra un servicio público de conversión de números a palabras, la misma forma que Apidog utiliza en su documentación. La operación es NumberToWords y toma un parámetro, ubiNum:
<?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>
El espacio de nombres de la operación debe coincidir con lo que el servicio espera, por eso lo lees del WSDL en lugar de adivinar. El soap:Body envuelve la llamada real; web:NumberToWords es la operación; web:ubiNum es la entrada.
Paso 3: enviar y leer la respuesta XML
Envía la solicitud. La respuesta regresa en XML, como un sobre SOAP cuyo Body contiene la operación de respuesta. Para la llamada anterior, obtienes una NumberToWordsResponse con el resultado anidado dentro:
<?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>
La respuesta refleja la solicitud: el nombre de la operación obtiene un sufijo Response, y el valor se ubica en un elemento de resultado. Esa replicación es contra lo que afirmas. Confirmas que el sobre regresó, que el nodo NumberToWordsResponse existe y que el resultado coincide con lo que esperabas. La documentación dedicada de WebService de Apidog en webservice.apidog.io contiene la referencia completa de configuración y más ejemplos de sobres si deseas un segundo ejemplo práctico.
Un caso de uso realista sigue los mismos tres pasos. Intercambia NumberToWords por una operación ConvertCurrency en un servicio heredado de tipo de cambio, pasa fromCurrency, toCurrency y amount como elementos anidados, y lee la cifra convertida del sobre de respuesta. O llama a una operación GetOrderStatus en un servicio web de pedidos, pasa un orderId, y verifica el nodo de estado devuelto. La mecánica nunca cambia: cabecera, cuerpo XML, enviar, leer el sobre.
Ruta B: importar un WSDL para generar los endpoints
Escribir sobres a mano está bien para una sola llamada. Cuando un servicio expone una docena de operaciones, deja que el WSDL haga el trabajo. Un archivo WSDL describe cada operación, sus entradas y la dirección del servicio, y Apidog lee todo eso en una sola importación.
Aquí tienes la ruta exacta de clics:
- Ve a Configuración, luego a Importar Datos.
- Selecciona
WSDL. - Sube tu archivo
.wsdlo.xml. - Revisa la vista previa de los endpoints API que Apidog analizó del archivo.
- Abre la pestaña
Environmentsy verifica que la dirección del servicio sea correcta. - Haz clic en
Confirmar. El entorno importado se crea automáticamente. - Selecciona el entorno importado desde la esquina superior derecha.
- Envía una solicitud. La URL Base se aplica automáticamente desde ese entorno.
Dos pasos de esa lista son los que la gente se salta y luego se arrepiente.
El paso 5 importa porque la dirección del servicio en el WSDL es el endpoint al que llegará cada solicitud importada. Si apunta a un host de staging, o a una URL de marcador de posición que el autor del WSDL nunca actualizó, tus solicitudes irán al lugar equivocado. Compruébalo en la pestaña Environments antes de hacer clic en Confirmar, no después.
El paso 7 importa porque la URL Base reside en ese entorno creado automáticamente. Si no seleccionas el entorno importado desde la esquina superior derecha, tus solicitudes no tendrán una dirección base y fallarán. Selecciónalo primero, luego envía.
Una vez importado, cada operación aparece como un endpoint que puedes llamar sin escribir el sobre tú mismo, y afirmas sobre la respuesta XML exactamente como en la Ruta A. Si estás migrando un proyecto completo de otra herramienta, nuestra guía para importar proyectos SOAP cubre la migración de principio a fin.
Una limitación honesta: la importación de WSDL está documentada para la carga de archivos .wsdl y .xml. La importación de un WSDL por URL o pegando su contenido no está documentada, así que sube el archivo en lugar de esperar un campo de URL.
Viniendo de SoapUI
Si tus pruebas SOAP residen actualmente en SoapUI, no tienes que reconstruirlas desde una página en blanco. Exporta o conserva tu WSDL, impórtalo en Apidog con la Ruta B, y obtendrás las mismas operaciones como endpoints invocables dentro de un espacio de trabajo que también realiza diseño, mocking y documentación. La ventaja es la consolidación: un solo proyecto alberga tu servicio SOAP, tus endpoints REST y tus escenarios de prueba, en lugar de dispersarlos entre herramientas separadas. Nuestra comparación de Apidog versus SoapUI detalla qué se transfiere y dónde difieren los flujos de trabajo.
Afirmaciones y variaciones
Una sola llamada exitosa demuestra que el endpoint está activo. Una prueba demuestra que es correcto. Una vez que tu solicitud SOAP regresa, añade afirmaciones sobre el sobre de respuesta: confirma que el nodo de operación de respuesta esperado está presente, extrae el elemento de resultado y verifica su valor contra lo que el contrato promete. Para un servicio de moneda, afirmas que el monto convertido es un número dentro del rango; para un servicio de pedidos, afirmas que el estado es uno de los valores permitidos.
A partir de ahí, construyes un escenario de prueba repetible que encadena llamadas, por ejemplo, crear un pedido y luego consultar su estado, pasando valores entre los pasos. Nuestro recorrido sobre cómo escribir un escenario de prueba con Apidog muestra cómo conectar los valores extraídos en solicitudes posteriores. El patrón es agnóstico al protocolo, por lo que un escenario puede mezclar una llamada SOAP con los endpoints REST a su alrededor.
Para endpoints seguros, SOAP comúnmente utiliza WS-Security para la mensajería cifrada y autenticada. Esa cabecera de seguridad es parte del sobre SOAP que envías, por lo que añades el bloque de seguridad wsse dentro de la cabecera del sobre junto con tu operación. La mecánica de envío sigue siendo la misma: configura el Content-Type, coloca el sobre completo, incluida la cabecera de seguridad, en el cuerpo XML y envía.
Automatiza el flujo de trabajo con la CLI de Apidog
Una vez que tus solicitudes SOAP o importadas de WSDL se guardan como escenarios de prueba, la CLI de Apidog las ejecuta desde la línea de comandos para que una pipeline pueda probarlas en cada push. Instálala con Node.js v16 o posterior, luego autentica:
npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
Ejecuta un escenario guardado por ID, contra el entorno que creó tu importación de WSDL:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli
Aquí -t es el ID del escenario de prueba, -e es el ID del entorno, y -r es el reportero (cli, html o junit, separados por comas para varios). Una advertencia honesta: la documentación confirma que el ejecutor ejecuta escenarios y suites de prueba guardados, pero no indica si los escenarios construidos sobre pasos SOAP se ejecutan de forma desatendida, así que trata la CLI como tu motor para los escenarios HTTP del proyecto y para mantener los endpoints importados de WSDL sincronizados en CI en lugar de asumir una ejecución específica de SOAP. Conectarlo a una pipeline se cubre en nuestra guía de CI/CD de la CLI de Apidog.
Preguntas frecuentes
¿Qué Content-Type debo usar para una solicitud SOAP? Ya sea text/xml; charset=utf-8 o application/soap+xml. El correcto depende del servicio: los endpoints SOAP 1.1 generalmente esperan el primero, los endpoints SOAP 1.2 el segundo. Configúralo manualmente en las cabeceras de la solicitud, y si obtienes un error de tipo de contenido, cambia al otro valor.
¿Necesito un plan de pago para probar SOAP en Apidog? El único requisito documentado es que Apidog sea la versión 2.1.31 o superior. No se menciona ninguna restricción de nivel de suscripción o autoalojamiento para el soporte de SOAP o WSDL, así que actualiza a una versión actual y estarás listo.
¿Puedo importar un WSDL desde una URL? La importación documentada de WSDL acepta la carga de archivos .wsdl y .xml. La importación por URL o pegando el texto del WSDL no está documentada, así que sube el archivo. Después de la importación, el entorno se crea automáticamente y lo seleccionas desde la esquina superior derecha antes de enviar.
¿Cómo pruebo APIs SOAP y REST en el mismo proyecto? Apidog las trata como tipos de solicitud dentro de un mismo espacio de trabajo, por lo que un solo proyecto puede contener operaciones SOAP junto a endpoints REST e incluso llamadas GraphQL. Si GraphQL también está en tu agenda, nuestra guía para probar APIs GraphQL en Apidog cubre ese aspecto, y un escenario de prueba puede encadenar solicitudes a través de todas ellas.
Mis solicitudes importadas de WSDL llegan al servidor equivocado. ¿Qué pasó? Dos causas habituales. O la dirección del servicio en la pestaña Environments era incorrecta en el momento de la importación y hiciste clic en Confirmar sin verificarla, o no seleccionaste el entorno importado desde la esquina superior derecha, por lo que no se aplicó ninguna URL Base. Vuelve a importar y verifica la dirección, luego asegúrate de que el entorno correcto esté activo antes de enviar.
Conclusión
Probar SOAP no tiene por qué significar una herramienta heredada separada. En Apidog, puedes enviar el sobre manualmente (configurar el Content-Type, establecer el cuerpo a xml, pegar el sobre, leer la respuesta XML) o importar un WSDL y dejar que Apidog construya los endpoints y el entorno por ti. Ambas rutas llegan al mismo lugar: una verificación repetible de que tu servicio web sigue respetando su contrato. Descarga Apidog en la versión 2.1.31 o superior, importa tu WSDL y somete tus servicios heredados a las mismas pruebas que el resto de tu superficie API.