JSON vs XML: quale scegliere?

Se hai mai integrato un'API enterprise datata o lavorato con feed RSS, hai già incontrato XML. Se hai costruito qualcosa sul web moderno, vivi in JSON. Entrambi i formati risolvono lo stesso problema di base — rappresentare dati strutturati come testo — ma lo fanno in modi molto diversi. Questo articolo analizza le differenze reali così puoi fare una scelta consapevole.

Gli Stessi Dati, Due Formati

Partiamo da un esempio concreto. Ecco un oggetto utente rappresentato in JSON:

{
  "user": {
    "id": 101,
    "name": "Bob",
    "email": "[email protected]",
    "roles": ["admin", "editor"],
    "active": true
  }
}

E qui gli stessi dati in XML:

<?xml version="1.0" encoding="UTF-8"?>
<user>
  <id>101</id>
  <name>Bob</name>
  <email>[email protected]</email>
  <roles>
    <role>admin</role>
    <role>editor</role>
  </roles>
  <active>true</active>
</user>

La versione JSON è di 62 caratteri. La versione XML è di 198 caratteri — 3× più grande per gli stessi dati. Su un payload piccolo non fa differenza. Su un'API ad alto traffico che serve milioni di richieste al giorno, la banda si accumula in fretta.

Dove Vince JSON

• Concisione. Niente tag di chiusura. Meno ripetizioni. Payload più leggeri in rete.
• Supporto nativo in JavaScript. JSON.parse() e JSON.stringify() sono integrati in ogni runtime JS. Nessuna libreria esterna necessaria.
• Semplicità. Sei tipi di dato, poche regole. Puoi leggere l'intera spec JSON in 10 minuti.
• Supporto nativo degli array. JSON ha array nativi. In XML sei costretto a ripetere elementi come <role> <role> <role>.
• Tooling. Database moderni come PostgreSQL, MongoDB e MySQL hanno tutti un supporto JSON di prima classe. La maggior parte delle piattaforme di logging parsa JSON nativamente.
• Leggibilità. Gli sviluppatori trovano JSON più facile da scorrere. Meno rumore da parentesi angolari e tag di chiusura.

Dove Vince Ancora XML

• Attributi e metadati. Gli elementi XML possono avere attributi: <user id="101" active="true">. Utile quando vuoi annotare i dati senza aggiungere elementi figlio.
• Namespace. I namespace XML ti permettono di mescolare vocabolari in un unico documento — fondamentale in formati come XHTML, SVG, SOAP e Office Open XML.
• Validazione tramite schema. XML Schema (XSD) offre una validazione potente e standardizzata con tipi di dato, pattern e cardinalità. JSON Schema sta recuperando terreno, ma XML Schema ha decenni di tooling alle spalle.
• Casi d'uso document-centric. XML è stato progettato per documenti, non solo per dati. Formati come XHTML, DocBook e DITA sono costruiti su XML e funzionano benissimo per contenuti con testo misto e markup.
• Trasformazioni XSLT. Puoi trasformare XML in HTML, altro XML o testo semplice usando XSLT — uno strumento potente per le pipeline di pubblicazione.
• Commenti. XML supporta i commenti. JSON no. Per i file di configurazione in cui vuoi spiegare il perché di un'impostazione, questo conta.

Performance: Conta Davvero?

Per la maggior parte delle applicazioni, la differenza di performance di parsing tra JSON e XML è irrilevante. Dove conta davvero — feed di dati ad alta frequenza, telemetria IoT, sistemi in tempo reale — JSON vince comodamente. I parser JSON sono più semplici e veloci perché il formato stesso è più semplice. Un benchmark rapido: il parsing di un file JSON da 1 MB in Node.js richiede tipicamente 10–30ms. L'equivalente XML, usando un parser SAX, è spesso 2–5× più lento, e un parser DOM è ancora peggio.

Se la performance è davvero critica, nessuno dei due formati è ideale — si passa a un formato binario come Protocol Buffers o MessagePack. Ma per il tipico lavoro su API web, la performance di JSON è più che adeguata.

Guida alla Scelta: Quando Usare Quale

Usa JSON quando:

• Costruisci API REST o GraphQL
• Archivi configurazioni o impostazioni (package.json, tsconfig.json, ecc.)
• Lavori con JavaScript, TypeScript, Python, Ruby, Go — qualsiasi linguaggio moderno
• Comunichi con qualsiasi API di terze parti moderna
• Archivi documenti in MongoDB, Elasticsearch o colonne PostgreSQL JSONB

Usa XML quando:

• Integri sistemi enterprise legacy (SAP, Salesforce SOAP API, ecc.)
• Lavori con formati documento: SVG, EPUB, Office Open XML (.docx, .xlsx)
• Pipeline di pubblicazione che usano trasformazioni XSLT
• Feed RSS / Atom
• Scambi dati in settori con standard XML consolidati (HL7 in sanità, FpML in finanza, ecc.)

Lavorare con Entrambi i Formati

A volte avrai bisogno di convertire tra i due. Magari stai consumando un'API XML legacy e vuoi archiviare i dati in JSON, o devi inviare dati a un servizio basato su XML da un backend nativo JSON. Puoi usare il convertitore da XML a JSON o il convertitore da JSON a XML per gestire queste trasformazioni. Per ispezionare le risposte XML, il XML Formatter e il XML Validator tornano utili.

Considerazioni Finali

JSON e XML risolvono lo stesso problema ma servono contesti diversi. JSON è la scelta giusta per la grande maggioranza dello sviluppo moderno — è più semplice, più leggero e ha un supporto nativo migliore in ogni linguaggio. XML ha punti di forza genuinamente unici nei casi d'uso document-centric e con namespace. La buona notizia è che non devi essere dogmatico — entrambi i formati sono maturi, ben supportati e coesisteranno a lungo. Conosci i tradeoff e scegli lo strumento giusto per il lavoro.