Web services: SOAP (WSDL, WS-Security) × REST (OpenAPI)

A ideia que organiza o assunto

Um web service existe para resolver um problema antigo: fazer dois sistemas que ninguém combinou conversarem — escritos em linguagens diferentes, rodando em sistemas operacionais diferentes, mantidos por equipes que nunca se falaram. A saída é sempre a mesma: publicar um contrato e esconder a implementação. O cliente só precisa saber o que o serviço faz, como chamá-lo e onde ele está; nunca se ele é uma classe Java, um procedimento COBOL ou um script.

Daí vem a primeira pergunta que resolve item: qual papel essa sigla exerce? A pilha clássica de web services divide o trabalho em três, e a prova vive de trocar um pelo outro:

WSDL descreve — o que o serviço faz, como se comunica, onde está.
UDDI publica e descobre — o catálogo, o registro onde o serviço é achado.
SOAP transporta — o envelope XML que leva a chamada e a resposta.

A segunda pergunta é de que mundo é a propriedade citada. SOAP é um protocolo: envelope XML obrigatório, contrato formal, independente de transporte. REST é um estilo arquitetural: um conjunto de restrições sobre recursos identificados por URI, sem estado, tipicamente sobre HTTP e com o formato que convier — JSON, XML, HTML. Quando o item dá a um o atributo do outro — SOAP com JSON, SOAP com URIs de recurso, REST guardando sessão, REST só com POST — ele está errado e você não precisou de mais nada.

Guarde a terceira só como reforço: descrever não é publicar, e publicar não é transportar. Quase todo item errado deste tópico cabe em uma dessas três perguntas.

Por que se usa (e o que custa)

SOAP compra rigor. O contrato WSDL é formal e processável por máquina: dá para gerar cliente e servidor a partir dele, validar a mensagem contra um esquema e exigir garantias de segurança fim a fim com WS-Security (assinatura e cifragem no nível da mensagem, não só do canal). Paga-se em verbosidade — todo XML, todo envelope — e em rigidez: qualquer mudança de contrato repercute nos dois lados.

REST compra simplicidade e alcance. Usa o que a web já tem: URI, verbos HTTP, códigos de status, cache, TLS. Paga-se em formalidade — o contrato não é obrigatório, e por isso surgiram Swagger/OpenAPI para reconstituir, no mundo REST, o que o WSDL dava no mundo SOAP. Um documento OpenAPI é para uma API REST o que um WSDL é para um serviço SOAP.

Nenhum dos dois é “melhor”: a prova cobra a troca, não a preferência.

Como funciona

O envelope SOAP. Toda mensagem é um documento XML com um Envelope que contém, no máximo, um Header e obrigatoriamente um Body. O Header é opcional e carrega metadados de infraestrutura — segurança, roteamento, transação, correlação; o Body é obrigatório e carrega a chamada ou a resposta. Erro vai dentro do Body, no elemento Fault. O modelo de processamento SOAP trata cada mensagem isoladamente: ele não coordena nem correlaciona mensagens por si só — correlação é conseguida por um valor comum combinado entre as partes (e é isso que padrões como WS-Addressing colocam no Header).

O WSDL. Responde a três perguntas, e é assim que ele é cobrado:

o que faz — types (tipos de dados, via XML Schema), message (as mensagens) e portType (as operações disponíveis);
como se comunica — binding (o protocolo concreto e a codificação; é ali que o atributo transport diz que as mensagens trafegam sobre HTTP);
onde está — service/port, com o endereço de rede efetivo em soap:address location.

Repare na armadilha embutida: portType descreve operações, não tipos de dados — quem define tipos é types. E o transport do binding aponta a tecnologia de transporte (http://schemas.xmlsoap.org/soap/http é o identificador de “SOAP sobre HTTP”), não o endereço onde o serviço será acessado.

O UDDI. É um registro — público ou privado, interno a uma organização ou aberto — para classificar, catalogar e gerenciar serviços. Guarda dados e metadados sobre os serviços (páginas brancas: quem; amarelas: categoria; verdes: como chamar, com ponteiros para o WSDL). O que ele não guarda são os documentos técnicos e de apoio ao desenvolvedor: o registro aponta para eles, não os hospeda. Um nó UDDI pertence a um único registro.

WS-Security. Aplica XML Signature (integridade e autenticidade) e XML Encryption (confidencialidade) às partes da mensagem SOAP, viajando no Header. A diferença que importa: HTTPS protege o canal e termina no primeiro intermediário; WS-Security protege a mensagem, sobrevivendo a intermediários.

REST. Recursos identificados por URI; representação devolvida no formato negociado (JSON, XML, HTML, o que o serviço suportar); interface uniforme com os verbos HTTP; e, sobretudo, ausência de estado: cada requisição carrega tudo o que é preciso para ser entendida, e o servidor não guarda sessão entre chamadas. Usar GET, POST, PUT e DELETE é condição necessária e longe de suficiente — RESTful exige o conjunto das restrições, não só os verbos.

OpenAPI/Swagger. Swagger é o conjunto de ferramentas (design, documentação, geração de código, teste); OpenAPI é a especificação. O documento descreve caminhos, operações, parâmetros, respostas e esquemas de segurança — inclusive bearer authentication na OpenAPI 3.0. Os esquemas seguem JSON Schema, onde format é opcional e, por padrão, anotativo: não valida sozinho, e o suporte a formatos (date, email, e os próprios da OpenAPI, como int32 e password) varia de ferramenta para ferramenta. O documento pode ser escrito em JSON ou em YAML — e YAML não precisa imitar a sintaxe do JSON, porque JSON é que é um subconjunto do YAML.

A vizinhança do tópico. XML é a base de tudo no lado SOAP: XML Schema oferece tipagem rica (essa é uma vantagem, não uma falta), XSLT transforma documentos usando XPath para navegar, e xsl:sort só ordena onde é permitido estar — como filho de xsl:for-each ou xsl:apply-templates. JSON é mais enxuto e mais rápido de analisar por ser um formato de dados puro, sem instruções de processamento nem metadados; XML é quem carrega metadados, atributos e espaços de nomes.

O que decide os itens

Papel de cada sigla — a distinção que decide mais itens que todas as outras somadas:

sigla	papel	uma frase que a identifica
SOAP	transporta	envelope XML com Header opcional e Body obrigatório
WSDL	descreve	o que faz, como se comunica, onde está
UDDI	publica e descobre	registro/catálogo de serviços, público ou privado
WS-Security	protege a mensagem	XML Signature + XML Encryption no Header
WS-BPEL	orquestra	composição de serviços em processo de negócio
OpenAPI/Swagger	descreve REST	o “WSDL do REST”
XML Schema (XSD)	tipa	define os tipos usados nas mensagens
XSLT (+XPath)	transforma	converte um documento XML em outro

SOAP × REST:

	SOAP	REST
natureza	protocolo	estilo arquitetural
formato	exclusivamente XML	JSON, XML, HTML, texto — negociável
contrato	WSDL (formal, obrigatório na prática)	OpenAPI (opcional)
endereçamento	um endpoint recebe todas as operações	cada recurso tem sua URI
verbos HTTP	usa HTTP como mero transporte (tipicamente POST)	usa GET/POST/PUT/DELETE com semântica
estado	pode manter, via extensões WS-*	sem estado, por restrição
segurança	WS-Security na mensagem	TLS/HTTPS no canal (+ OAuth, JWT)
descoberta	UDDI	documentação/OpenAPI, HATEOAS

Header × Body no SOAP — Header é opcional e traz metadados; Body é obrigatório e traz o conteúdo. Item que chama o Header de indispensável está errado.

types × portType — types define tipos de dados; portType define operações. Trocar os dois é o erro de WSDL mais frequente.

transport × location — transport, no binding, diz sobre que tecnologia a mensagem trafega; location, no port, diz o endereço. A URI http://schemas.xmlsoap.org/soap/http é identificador de transporte, não endereço de acesso.

REST × RESTful — usar verbos HTTP não torna a API RESTful automaticamente; faltam as demais restrições (interface uniforme, ausência de estado, cache, camadas). Achou “automaticamente” ou “basta”, desconfie.

Web service × SOAP — web service é o conceito (interação máquina a máquina por rede, com interface processável por máquina); SOAP é uma das formas de realizá-lo. Item que define web service como “necessariamente SOAP” ou como algo que liga o usuário à aplicação troca o conceito pela implementação.

Independência do quê — web service independe de linguagem, de plataforma, de sistema operacional e de hardware. Qualquer item que crie uma dependência (“desde que ambos usem a mesma linguagem”, “depende do sistema operacional”) está errado por isso.

CORBA × mensageria — CORBA é middleware de objetos distribuídos, de invocação tipicamente síncrona, com as duas pontas disponíveis. Quem entrega sem que o destino esteja on-line no instante do envio é a mensageria (filas, MOM).

Princípios SOA (Erl) — contrato padronizado, baixo acoplamento, abstração, reusabilidade, autonomia, ausência de estado, descoberta e composição. O objetivo declarado do contrato de serviço padronizado é justamente evitar transformação de dados entre consumidores — e é por o contrato ser fisicamente desacoplado da implementação que ele pode ser padronizado sozinho.

Números que caem


SOAP 1.1 × SOAP 1.2	Nota W3C (2000) × Recomendação W3C (2003); `text/xml` × `application/soap+xml`
elementos do Envelope	`Header` opcional + `Body` obrigatório; `Fault` dentro do Body
elementos maiores do WSDL 1.1	`types`, `message`, `portType`, `binding`, `service` (com `port`)
WSDL 2.0	`portType` → `interface`; `port` → `endpoint`; `message` deixa de existir
páginas do UDDI	3 — brancas (quem), amarelas (categoria), verdes (como chamar)
nó × registro UDDI	um nó pertence a um único registro
restrições REST	6 — cliente-servidor, sem estado, cache, interface uniforme, camadas e code on demand (a única opcional)
maturidade de Richardson	níveis 0 a 3: XML sobre HTTP · recursos · verbos HTTP · HATEOAS
classes de status HTTP	2xx sucesso · 3xx redirecionamento · 4xx erro do cliente · 5xx erro do servidor
versões OpenAPI	Swagger 2.0 → OpenAPI 3.0 (2017) → 3.1 (alinhada ao JSON Schema)
códigos de falha SOAP 1.1	`VersionMismatch`, `MustUnderstand`, `Client`, `Server` (1.2: `Sender`/`Receiver`)

Como a CEBRASPE derruba você aqui

Inversão — mais de um terço dos itens errados, e o eixo é sempre SOAP × REST. Duas descrições corretas, nos lugares trocados: o SOAP elogiado por “a sua utilização correta dos métodos HTML (PUT, GET, POST, DELETE), enquanto o REST utiliza apenas o método POST” — os verbos com semântica são do REST, e o SOAP usa o HTTP como mero transporte. O REST recebendo estado: “no RESTful, as transações são inter-relacionadas, ou seja, não pode haver serviços autônomos”; um servidor REST que “armazena informações de outras sessões a respeito das solicitações”. O XML e o JSON trocados: escolhe-se “o JSON, quando são exigidas informações de metadata” — metadado é a força do XML. O mesmo movimento inverte obrigatoriedade: o Header do SOAP “é um elemento indispensável, uma vez que ele informa o endereço da mensagem” (é o Body que é obrigatório); o format do JSON Schema “é obrigatório — de modo que sua ausência invalida o esquema” (é opcional e anotativo); o envelope SOAP “que independe de XML”; o DTD contra o XSD, com “a falta de suporte a diferentes tipos de dados” atribuída ao lado errado; “dados YAML devem adotar estrutura e sintaxe compatíveis com o formato JSON”, quando é o JSON que é subconjunto do YAML. E inverte a razão de existir do web service, criando a dependência que ele justamente elimina: funciona “desde que os códigos em ambas as partes utilizem a mesma linguagem de programação”; a interoperabilidade “depende dos sistemas operacionais”. Confira o par, não cada metade — e, diante de uma dependência de linguagem, plataforma ou SO, o item já está errado.

Atribuição errada de papel — 30% dos itens errados, muito acima do que esse molde rende em outros tópicos. É a marca deste assunto: uma ação real da pilha aparece assinada pela sigla vizinha. “A UDDI (universal description, discovery and integration) estabelece um formato padrão de mensagem” — formato de mensagem é do SOAP. “O UDDI é uma linguagem usada para a formatação de documentos JSON.” “Sendo o padrão UDDI utilizado especificamente para a definição formal das mensagens trocadas entre cliente e servidor” — quem define formalmente é o WSDL. O WSDL “responsável por encontrar um serviço e sua descrição na Web” — descobrir é do UDDI. “As linguagens XML e SOAP são utilizadas para descrever os tipos e as estruturas de dados” — quem tipa é o XML Schema. O SOAP “no suporte nativo a descrições de serviço via URIs para identificar recursos” — identificar recurso por URI é do REST. “A mensagem SOAP pode ser codificada com o uso de JSON” — o SOAP é exclusivamente XML. E, dentro do próprio WSDL, “o termo transport indica que o ESB será acessado por meio da URL a seguir” — transport diz a tecnologia, location diz o endereço. A defesa é mecânica: antes de julgar, diga em voz alta o verbo de cada sigla — SOAP transporta, WSDL descreve, UDDI registra e descobre, XML Schema tipa — e confira qual verbo o item usou.

Troca de termo — um quinto, e boa parte na sintaxe. O elemento errado do WSDL: “o elemento portType provê as definições de tipos de dados”, quando types define tipos e portType define operações. O documento XML mal formado, com <nome>Água<nome> sem a barra de fechamento. O objeto JSON escrito como [marca:"ABC";modelo:"G5";ano:"2019"], com colchetes, sem aspas nos nomes e com ponto e vírgula no lugar da vírgula. “As solicitações e respostas são escritas em HTML” para a mensagem SOAP. Fora da sintaxe, os nomes vizinhos de sempre: o web service que serve “para conectar o usuário a uma aplicação remota”, quando a interação é máquina a máquina; a integração “do tipo nativa” recebendo a definição da personalizada; a extranet descrita como “uma rede de uso público”.

Generalização. “Exclusivamente”, “automaticamente”, “qualquer ponto”. Usar os verbos HTTP não torna a API “automaticamente, um serviço RESTful” — é condição necessária, não suficiente. A API não serve “exclusivamente para o intercâmbio de dados entre sistemas baseados na mesma linguagem de programação”. O xsl:sort não vale “em qualquer ponto do documento”, só dentro de for-each ou apply-templates. Achado o absoluto, procure o contraexemplo que ele exclui.

Itens de código e de front-end. O tópico carrega uma minoria de itens que pedem leitura de código em vez de especificação, e neles o alvo é o alcance de uma expressão ou a fronteira de um laço. Um replaceAll("[^a-zA-Z]", "") sobre "22 TJ PA" remove justamente os dígitos e os espaços e devolve TJPA, mas o item afirma que “apresentará 22 como resultado”. Um laço sobre quatro posições declarado for (let i = 1; i < desc.length-2; ++i) roda uma única vez, com i igual a 1, e imprime só “Contas do” — o item anuncia “Tribunal de Contas do”, contando com um laço que começasse em zero. Cabe aqui também a causa inventada — o JSON é rápido “devido ao fato de ser capaz de executar instruções de processamento”, quando é rápido por ser simples — e o CSS3 que “exige a instalação de um plug-in na parte cliente da aplicação”, interpretado nativamente pelo navegador.

Erros clássicos

Achar que web service é sinônimo de SOAP. Web service é o conceito de interação máquina a máquina com interface processável por máquina; SOAP e REST são os dois caminhos mais usados para chegar lá.

Confundir descrever, publicar e transportar. WSDL descreve, UDDI publica, SOAP transporta. Nenhum dos três faz o trabalho do outro.

Chamar REST de protocolo. REST é estilo arquitetural, um conjunto de restrições; SOAP é que é protocolo. E API RESTful é a que atende às restrições, não a que expõe quatro verbos.

Supor que o UDDI hospeda a documentação. Ele cataloga e aponta; os documentos técnicos ficam fora do registro.

Trocar portType por types. Operações e tipos de dados são elementos distintos do WSDL — e é o par mais cobrado do documento.

Confundir Swagger com um meio de comunicação. Swagger/OpenAPI descreve e documenta a API; quem troca dados é a API.

Tratar HTTPS e WS-Security como a mesma coisa. Um protege o canal e termina no intermediário; o outro protege a mensagem e atravessa intermediários.

Achar que o XML Schema é pobre em tipos. É o contrário: tipagem rica é justamente a vantagem do XSD sobre o DTD.

Achar que o JSON é mais rápido por “processar instruções”. É mais rápido por ser simples — sem instruções de processamento, sem espaços de nomes, sem metadados. Quem tem tudo isso é o XML.