XML Não Está Morto (Infelizmente) — Converta para JSON Como um Adulto

Você aprendeu REST. Aceitou JSON. Acreditou que a era do XML havia acabado, como o Flash ou o IE6 — algo que você avisaria aos desenvolvedores juniors como uma história de fogo de campa. Então, seu novo cliente entregou as credenciais da API para a integração bancária, e lá estava: uma envelope SOAP de 400 linhas olhando de volta para você.

Bem-vindo de volta ao XML. Ele nunca saiu.

Por que o XML ainda está por toda parte

Para muitos desenvolvedores construindo aplicações modernas, o XML parece um relicário. Mas no mundo real — especialmente em software empresarial, bancário, de saúde e sistemas governamentais — o XML é infraestrutura absolutamente essencial. Aqui é onde você vai encontrá-lo:

• Serviços web SOAP – Ainda é o padrão para instituições financeiras, plataformas de seguros e grandes sistemas ERP. Sua integração fintech provavelmente passa por um desses.
• APIs bancárias – As mensagens ISO 20022, os mensagens SWIFT e muitas APIs centrais de bancos comunicam em XML. Não há opção de REST.
• Dados governamentais – O HMRC, o IRS e a maioria dos portais governamentais aceitam ou retornam XML. Isso não mudará em breve.
• Middleware empresarial – Sistemas SAP, Oracle e sistemas legados de ESB falam nativamente em XML. Se você estiver integrando com algo de nível empresarial, é provável que você encontre XML.
• Feeds RSS e Atom – Ainda XML. Muitas pipelines de conteúdo, agregadores de notícias e ferramentas de monitoramento dependem disso.

A verdade incômoda: o XML não vai embora porque os sistemas construídos sobre ele não vão embora. Substituir a infraestrutura central de um banco não é uma tarefa de sprint. Então, você se adapta.

XML versus JSON: As Diferenças Estruturais que Realmente Você Encontra

Antes de começar a converter, ajuda entender por que a conversão de XML para JSON não é apenas uma troca de formato. Os dois formatos modelam os dados de maneiras diferentes, e essas diferenças criam verdadeiros problemas.

Lado a lado: Os Mesmos Dados nos Dois Formatos

Pegue uma simples ordem de cliente. Aqui está em XML:

<order id="ORD-1042" currency="GBP">
  <customer>
    <name>Alice Martin</name>
    <email>alice@example.com</email>
  </customer>
  <items>
    <item sku="PRD-001">
      <description>Wireless Keyboard</description>
      <quantity>1</quantity>
      <price>49.99</price>
    </item>
    <item sku="PRD-007">
      <description>USB-C Hub</description>
      <quantity>2</quantity>
      <price>29.99</price>
    </item>
  </items>
</order>

E aqui está a versão equivalente em JSON:

{
  "order": {
    "@id": "ORD-1042",
    "@currency": "GBP",
    "customer": {
      "name": "Alice Martin",
      "email": "alice@example.com"
    },
    "items": {
      "item": [
        {
          "@sku": "PRD-001",
          "description": "Wireless Keyboard",
          "quantity": "1",
          "price": "49.99"
        },
        {
          "@sku": "PRD-007",
          "description": "USB-C Hub",
          "quantity": "2",
          "price": "29.99"
        }
      ]
    }
  }
}

Já você pode ver os pontos de atrito estruturais. Vamos analisá-los.

Atributos versus Chaves

Elementos XML podem carregar atributos (id="ORD-1042") ao lado de elementos filhos e conteúdo de texto. O JSON não tem conceito de atributos — tudo é uma paridade chave-valor. A convenção mais comum é prefixar atributos com @ ao converter, dando-lhe "@id": "ORD-1042". Alguns analisadores usam $ ou os flatten completamente. A convenção importa porque o código consumidor precisa saber qual prefixo esperar.

Arrays versus Elementos Repetidos

Este é um ponto que engana constantemente os desenvolvedores. No JSON, um array é explícito: [...]. No XML, não há essa distinção — elementos irmãos repetidos são implicitamente uma lista. Um analisador que vê um <item> elemento pode retornar um objeto. Dois <item> elementos? Ele retorna um array. Seu código quebra quando a API retorna um único resultado.

A solução é forçar arrays para campos conhecidos como listas, ou usar uma biblioteca que preserve a informação de tipo. Quando você está convertendo dados isolados, verifique se um campo que parece um objeto único pode, às vezes, ser uma lista em payloads de produção.

Nós de texto e conteúdo misto

Elementos XML podem conter ao mesmo tempo conteúdo de texto e elementos filhos (conteúdo misto). O JSON não pode representar isso de forma limpa. Analisadores lidam com isso de maneiras diferentes — alguns usam uma #text chave, outros usam _, outros simplesmente descartam o conteúdo misto. Se você estiver convertendo XML com conteúdo misto, verifique manualmente a saída.

Namespaces

Respostas SOAP estão cheias de namespaces XML: <ns2:getOrderResponse xmlns:ns2="http://...">. De acordo com seu analisador, esses namespaces são removidos, reduzidos ao nome da chave (ns2:getOrderResponse) ou mapeados para uma URI. A maioria das vezes você quer removê-los, mas se dois namespaces compartilham um nome de elemento, você perde a distinção. Conheça o que você está lidando antes de assumir que a saída é limpa.

O caminho rápido: converter XML online sem escrever um analisador

Se você estiver debugando uma resposta de API, explorando um esquema XML desconhecido ou fazendo uma conversão de umas vez, escrever um analisador é excessivo. Use o Conversor XML para JSON — cole seu XML, obtenha JSON limpo de volta instantaneamente e inspecione a estrutura antes de escrever qualquer código.

Ele trata atributos (com convenção de prefixo @ ), elementos aninhados, elementos repetidos como arrays e preserva o conteúdo de texto — o que cobre a maioria dos payloads reais de API. Útil para entender rapidamente o que uma resposta SOAP realmente parece quando o envelope é reduzido ao conteúdo de dados.

Conversão programática: o que usar em produção

Para códigos de produção integrando APIs XML, você quer uma biblioteca adequada em vez de escrever um analisador do zero. Aqui estão as opções principais por linguagem:

JavaScript / Node.js

import { XMLParser } from 'fast-xml-parser';

const parser = new XMLParser({
  ignoreAttributes: false,
  attributeNamePrefix: '@',
  isArray: (name) => ['item', 'product', 'order'].includes(name),
});

const result = parser.parse(xmlString);

fast-xml-parser é a melhor escolha para Node.js. Use isArray para forçar o tratamento como array para elementos conhecidos de lista — isso previne o erro de inconsistência entre um item e um array que eventualmente atingirá você em produção.

Pitão

import xmltodict

with open('response.xml') as f:
    data = xmltodict.parse(f.read())

import json
print(json.dumps(data, indent=2))

xmltodict é a escolha padrão em Python. Usa a convenção @ para atributos e #text para nós de texto. Observe que ele retorna um OrderedDict, que serializa bem com json.dumps.

PHP

$xml = simplexml_load_string($xmlString);
$json = json_encode($xml);
$data = json_decode($json, true);

PHP’s simplexml_load_string + json_encode é o caminho rápido, mas trata atributos de forma inconsistente e pode perder dados em casos extremos. Para trabalhos de produção com respostas SOAP, considere DOMDocument com LIBXML_NOBLANKS ou uma biblioteca dedicada.

Erros comuns a serem monitorados

• Números saem como strings. O XML não tem tipo numérico — tudo é texto. Seu campo de preço será "49.99", e não 49.99. Converta explicitamente após a conversão.
• Valores booleanos permanecem como strings. <active>true</active> torna-se "active": "true". Verifique antes de usá-los em condições.
• Elementos vazios tornam-se null ou objetos vazios. <middleName/> pode converter-se para null, "", ou {} de acordo com o analisador. Teste o caso limite.
• Seções CDATA podem ou não ser preservadas. Se a API usa CDATA para escapar conteúdo HTML, verifique se o analisador o trata e não o remove silenciosamente.
• A ordem não é garantida. A ordem dos elementos XML pode ser significativa em alguns esquemas; a ordem das chaves em um objeto JSON não é. Se a sequência importa para o sistema consumidor, trate explicitamente.

Trabalhando especificamente com SOAP

O SOAP adiciona uma camada extra sobre o XML: cada resposta está envolvida em um <Envelope> com um <Body>, muitas vezes decorado com declarações de namespace e um bloco <Header> . Antes de converter para JSON, você geralmente quer extrair apenas o conteúdo do corpo.

Em Python com zeep (o cliente SOAP), você obtém objetos Python diretamente e não precisa analisar XML por si só. Em Node.js, soap e strong-soap faça o mesmo. Se você estiver atingindo um ponto de extremidade SOAP diretamente com fetch ou axios, você precisará remover manualmente o envelope antes de executar seu conversor XML para JSON.

Para inspeção rápida de respostas SOAP, o Conversor XML para JSON é útil — cole o envelope completo, veja a estrutura completa e descubra qual caminho leva ao dado que você realmente precisa.

Aceite a realidade e continue

Há um tipo de dor que surge ao perceber que seu projeto de início limpo precisa integrar com uma API SOAP construída em 2003. Deixe-se sentir com isso, depois continue. O XML é um problema resolvido — os analisadores são maduros, as ferramentas de conversão existem e os problemas são bem documentados. Você não é o primeiro desenvolvedor a enfrentar um envelope de 400 linhas.

Use a biblioteca adequada para sua linguagem, trate explicitamente a conversão de tipos, force arrays para campos conhecidos como listas e teste com payloads reais em vez dos exemplos idealizados nos documentos da API. Os documentos mostrarão um item; a produção enviará cinquenta.

E para o trabalho exploratório — entender um esquema XML desconhecido, validar uma conversão antes de escrever código — mantenha o Conversor XML para JSON em sua lista de favoritos. É mais rápido do que rodar um script toda vez que você precisa inspecionar um payload.

Você também pode gostar