SOAP não desapareceu. Sistemas bancários, gateways de pagamento, serviços governamentais e plataformas empresariais mais antigas ainda expõem endpoints SOAP, e alguém precisa testá-los. Se você passou sua carreira em REST e JSON, um serviço SOAP pode parecer estranho. O protocolo é mais rigoroso, os payloads são XML e o contrato reside em um arquivo WSDL separado.
A boa notícia é que testar uma API SOAP online não é difícil, uma vez que você entende o que ela realmente espera de você. Este guia explica como o teste SOAP difere do teste REST, percorre uma requisição real e aborda as ferramentas online que lidam com SOAP sem complicações.
Por que o teste SOAP é diferente
REST é um estilo. SOAP é um protocolo com regras. Essa distinção molda tudo sobre como você o testa.
Uma mensagem SOAP é sempre um documento XML envolvido em um envelope. O envelope tem um cabeçalho para metadados como autenticação ou roteamento, e um corpo que contém a operação real e seus parâmetros. Você não pode simplesmente enviar um objeto JSON solto. A estrutura é obrigatória, e um envelope malformado é rejeitado antes mesmo de sua lógica ser executada. SOAP também quase sempre viaja via HTTP POST, mesmo para operações que apenas leem dados, e espera um Content-Type específico, geralmente text/xml ou application/soap+xml.
A maior diferença prática é o WSDL. Um WSDL, ou Web Services Description Language, é um contrato legível por máquina que lista todas as operações que o serviço oferece, o formato exato de cada requisição e resposta, e o endereço do endpoint. REST raramente entrega algo tão rigoroso. Quando você testa SOAP, o WSDL é seu mapa. Um bom testador SOAP online lê o WSDL e gera modelos de requisição para você, para que você não precise digitar envelopes de memória. Se você quiser uma visão mais ampla do contrato, nossas notas sobre teste de contrato de API explicam por que um contrato rigoroso é um ativo.
Como uma requisição SOAP realmente se parece
Aqui está uma requisição SOAP realista para um serviço de conversão de moeda. Observe o envelope, as declarações de namespace e a operação aninhada no corpo.
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>
A resposta retorna da mesma forma:
<?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>
Dois detalhes confundem as pessoas. O cabeçalho HTTP SOAPAction é exigido por muitos serviços e deve corresponder à operação, ou você receberá uma falha. E quando algo falha, SOAP não retorna um HTTP 400 com uma mensagem organizada. Ele retorna HTTP 200 com um elemento <soap:Fault> dentro do corpo. Seu teste precisa analisar o corpo para saber se a chamada realmente foi bem-sucedida. Verificar apenas o código de status não é suficiente, o que é uma das razões pelas quais as asserções de API estruturadas importam mais aqui do que em REST.
Ferramentas online para testar APIs SOAP
Apidog
Apidog lida com SOAP junto com REST, GraphQL e WebSocket em um só lugar. Você importa um WSDL, e ele gera a estrutura da requisição para que você não precise construir envelopes manualmente. Você pode adicionar asserções em elementos XML, encadear requisições em um cenário e executar tudo como um conjunto automatizado. Como ele também projeta e simula APIs, você pode simular uma resposta SOAP antes que o serviço real esteja pronto. Baixe o Apidog para testar serviços SOAP na versão gratuita.
SoapUI
SoapUI é a ferramenta original de teste SOAP e ainda a mais completa. Aponte-o para um WSDL e ele constrói um projeto com cada operação. A edição de código aberto é gratuita e robusta para testes funcionais e orientados a dados de SOAP. É uma aplicação de desktop Java mais pesada, e os recursos de relatórios mais polidos estão na versão paga ReadyAPI. Para uma visão mais detalhada, veja o que é o SoapUI e como funciona.
Postman
Postman pode enviar requisições SOAP. Você define o corpo como XML bruto, adiciona os cabeçalhos Content-Type e SOAPAction manualmente e cola seu envelope. Funciona, mas o Postman não analisa um WSDL, então você constrói os envelopes sozinho. É bom para uma verificação pontual e menos confortável para uma grande superfície SOAP.
Testadores SOAP baseados em navegador
Várias ferramentas web leves permitem que você cole uma URL WSDL e dispare requisições de uma aba do navegador. Elas são úteis para uma verificação rápida sem necessidade de instalação. Os limites aparecem rapidamente: suporte limitado a asserções, pouca ou nenhuma automação e nenhuma maneira de organizar um conjunto de testes real. Use-as para confirmar se um endpoint está ativo, não para construir um conjunto de regressão.
Um fluxo de trabalho rápido para testes SOAP
- Obtenha o WSDL. A maioria dos serviços SOAP o expõe adicionando
?wsdlà URL do endpoint. Abra-o e confirme se carrega. - Importe o WSDL para sua ferramenta. Apidog e SoapUI geram modelos de requisição a partir dele. Este é o maior economizador de tempo.
- Preencha os parâmetros da operação. Use valores reais. Teste uma conversão de moeda com um valor real e códigos de moeda válidos.
- Defina os cabeçalhos. Confirme
Content-Typee, quando necessário,SOAPAction. UmSOAPActionausente é a causa mais comum de uma falha inexplicável. - Envie e inspecione o corpo. Não pare no status HTTP. Abra o corpo da resposta e verifique se há
<soap:Fault>. - Adicione asserções. Afirme que um elemento específico existe e contém o valor esperado. Em seguida, encadeie uma chamada de acompanhamento, se seu fluxo precisar.
Para organizar isso em um conjunto mantenível, nosso guia sobre construção de conjuntos de testes para automação de API se aplica diretamente ao trabalho com SOAP.
Falhas SOAP e como asserir sobre elas
Uma falha SOAP é a estrutura de erro do protocolo. Ela contém um faultcode, um faultstring e, às vezes, um elemento detail. Como chega com um HTTP 200, um teste que verifica apenas o status passará em uma chamada que falhou. Isso é um falso positivo silencioso e perigoso.
Escreva suas asserções SOAP para olhar dentro do corpo. Assegure que nenhum elemento <soap:Fault> esteja presente em um caminho de sucesso. Em um caminho de erro deliberado, afirme o oposto, que a falha aparece e o faultcode corresponde ao que você espera. Testar os casos de falha é tão importante quanto o caminho feliz, porque os serviços SOAP frequentemente codificam regras de negócio, como uma transação recusada, como falhas em vez de dados. A documentação de falhas SOAP do W3C descreve a estrutura se você precisar dos detalhes formais.
WS-Security adiciona outra camada. Muitos serviços SOAP empresariais esperam um cabeçalho de segurança assinado ou com token. Se suas requisições falharem com uma falha de autenticação, o WSDL ou a documentação do serviço dirá qual perfil de segurança está em jogo. Ferramentas como SoapUI e Apidog permitem configurar esses cabeçalhos em vez de criar o XML manualmente.
Lendo um WSDL sem se perder
Um arquivo WSDL parece intimidante na primeira vez que você o abre. É um XML longo e profundamente aninhado, e a maior parte dele é "encanamento" de máquina. Você não precisa ler tudo. Quatro partes contêm as informações que você realmente deseja.
A seção types define as estruturas de dados, geralmente como XML Schema, então é aqui que você aprende a forma exata e as restrições de cada parâmetro. Os elementos message descrevem a entrada e a saída para cada operação. O portType lista as próprias operações, que são as chamadas que você pode fazer. As seções service e binding fornecem o endereço concreto do endpoint e os detalhes de transporte. Quando você importa um WSDL para uma ferramenta, ela lê todas as quatro e as transforma em requisições prontas para edição, o que é o motivo pelo qual importar supera digitar manualmente a cada vez.
Um detalhe que vale a pena saber: um WSDL pode ser dividido em vários arquivos usando declarações import, frequentemente puxando esquemas de locais separados. Se sua ferramenta relatar um tipo ausente, um arquivo referenciado provavelmente falhou em resolver. Certifique-se de que cada URL importada seja acessível de onde sua ferramenta está sendo executada. Esse tipo de dependência de contrato é exatamente por que as equipes tratam o WSDL como um artefato versionado, em vez de algo que vive apenas em um servidor.
Teste SOAP orientado a dados
Os serviços SOAP frequentemente carregam regras de negócio rigorosas, e uma única requisição de "caminho feliz" raramente prova muito. Um serviço de moeda deve ser testado com pares válidos, com uma moeda não suportada, com um valor zero e com um valor negativo. Um serviço de pagamento deve ser testado com um cartão aprovado, um cartão recusado e um vencido. Digitar cada um desses casos manualmente é lento e fácil de errar.
O teste orientado a dados resolve isso. Você escreve a requisição uma vez com placeholders e, em seguida, alimenta-a com uma tabela de linhas de entrada e resultados esperados. A ferramenta executa a requisição para cada linha e verifica cada resultado. O SoapUI suporta esse padrão há anos, e o Apidog o suporta por meio de seu executor de cenários. A recompensa é uma cobertura real dos casos de borda que os serviços SOAP tendem a codificar como falhas. Para o padrão mais amplo, nosso guia sobre teste de API orientado a dados com CSV e JSON explica como estruturar os dados de entrada, e isso se aplica a SOAP da mesma forma que a REST.
Perguntas frequentes
Qual a diferença entre o teste SOAP e REST?
O teste SOAP funciona com um protocolo XML rigoroso com um contrato WSDL, envelopes obrigatórios e falhas retornadas dentro de um corpo HTTP 200. O teste REST geralmente lida com JSON, convenções mais flexíveis e códigos de status HTTP significativos. Um teste SOAP deve analisar o corpo da resposta para confirmar o sucesso; um teste REST geralmente pode confiar no código de status.
Preciso do WSDL para testar uma API SOAP?
Você pode enviar uma requisição SOAP sem ele se já souber a estrutura exata do envelope. Mas o WSDL torna o teste muito mais fácil porque as ferramentas geram modelos de requisição corretos a partir dele. A maioria dos serviços expõe o WSDL adicionando ?wsdl à URL do endpoint. Sempre comece por aí.
Por que minha requisição SOAP retorna uma falha, mesmo com o status 200?
SOAP reporta erros como um elemento <soap:Fault> dentro do corpo, não como um código de erro HTTP, então um 200 com uma falha é normal. As causas usuais são um cabeçalho SOAPAction ausente ou incorreto, um envelope malformado, uma incompatibilidade de namespace ou uma falha na verificação de segurança. Leia o faultstring para o motivo específico.
Posso testar APIs SOAP online gratuitamente?
Sim. Apidog suporta SOAP em sua versão gratuita e importa arquivos WSDL, e a edição de código aberto do SoapUI é construída para SOAP. Testadores leves baseados em navegador também existem para verificações rápidas, embora não ofereçam suporte real a asserções e automação.
Como automatizo testes de API SOAP?
Importe o WSDL, construa um cenário que encadeie as operações em ordem, adicione asserções nos elementos da resposta e na ausência de falhas, e então execute-o a partir do executor de uma ferramenta ou em seu pipeline de CI. SoapUI e Apidog suportam conjuntos SOAP agendados e acionados por pipeline, então uma execução de regressão SOAP se encaixa no mesmo fluxo de automação que REST.