Risposte:
Favorire XML su JSON quando uno di questi è vero:
Favorire JSON su XML quando tutti questi sono veri:
Uso JSON a meno che non mi venga richiesto di utilizzare XML. È più semplice da capire e (poiché richiede meno sovraccarichi di configurazione) è più facile programmare per leggere e scrivere se le librerie sono disponibili nel tuo contesto e sono piuttosto onnipresenti ora.
Quando Amazon ha esposto per la prima volta i propri cataloghi come servizio Web, ha offerto sia JSON che XML. Qualcosa come il 90% degli implementatori ha scelto JSON.
Considerando il tuo caso specifico in cui stai già eseguendo JavaScript sul lato client, andrei con JSON per questi motivi:
Dato che JSON è nativo di JavaScript dovresti scrivere meno codice sul lato client - Solo eval() (o, meglio ancora, JSON.parse()) la stringa JSON e ottenere un oggetto che puoi usare.
Allo stesso tempo, la valutazione di JSON sul lato client sarà più efficiente e quindi più rapida.
La serializzazione JSON produce stringhe più brevi di XML. L'uso di JSON ridurrà la quantità di dati in esecuzione attraverso il cavo e migliorerà le prestazioni al riguardo.
Ecco qualche ulteriore lettura: http://www.subbu.org/blog/2006/08/json-vs-xml
eval()JSON non è un grande no-no?
Alcune altre cose in cui mi sono imbattuto nel relm XML vs JSON:
JSON è ottimo per
Ciò significa che tende ad apprezzare un array o un array nidificato. Tuttavia, a JSON mancano entrambi
Quindi, se dovessi combinare due o più servizi JSON potrebbero esserci potenziali conflitti nello spazio dei nomi. Detto questo, JSON può essere utilizzato per circa il 90% delle stesse cose per cui XML può essere utilizzato quando si scambiano dati nella mia esperienza.
Di solito JSON è più compatto e più veloce da analizzare.
Preferisci XML se:
Un caso importante di (quasi) XML: provare a rilevare quando si inviano snippet HTML è più vantaggioso che inviare dati non elaborati. AHAH può fare miracoli in applicazioni semplici, ma spesso trascurate. In genere questo stile presuppone che un server invii frammenti HTML che verranno incorporati nella pagina Web senza essere elaborati.
Di solito, nei casi AHAH, il CSS viene sfruttato al massimo per massaggiare visivamente i frammenti e implementare semplici condizionali come nascondere / mostrare parti rilevanti del frammento utilizzando impostazioni specifiche dell'utente o dell'applicazione.
JSON è facile e veloce da analizzare. XML è un po 'più difficile da analizzare ed è più lento da analizzare e trasferire (nella maggior parte dei casi).
Dato che stai usando jQuery, ti suggerisco di usare JSON: jQuery può recuperare i dati JSON e convertirli automaticamente in un oggetto Javascript. In effetti, puoi convertire i dati JSON in un oggetto Javascript usando eval . L'XML dovrebbe essere attraversato manualmente da te (non so come funziona in Javascript, ma è difficile / più fastidioso nella maggior parte dei linguaggi con cui ho usato le librerie XML).
JSON è sempre preferibile in termini di elaborazione che il browser client deve eseguire per l'analisi dei dati. Inoltre, JSON è un formato di scambio dati leggero.
L'analisi XML consuma sempre molte risorse del browser e dovrebbe essere evitata il più possibile se non diversamente richiesto.
Ho un post sul blog sull'argomento che descrive in dettaglio la storia dei protocolli web (ad esempio SOAP, XML, JSON, REST, POX, ecc.) Fornendo un riepilogo e alcuni vantaggi e svantaggi di ciascuno: http://www.servicestack.net / mythz_blog /? p = 154
In realtà penso che tu possa tracciare molte somiglianze tra XML e JSON confrontando le differenze tra i linguaggi dinamici (JSON) e statici (XML).
Fondamentalmente XML è un formato di serializzazione più rigido e più rigido che può essere facoltativamente verificato con uno schema di accompagnamento (che è un XSD o DTD). Gli XSD sono piuttosto elaborati e ti consentono di descrivere molti tipi diversi, ad esempio date, orari, enumerazioni, tipi definiti dall'utente e persino ereditarietà dei tipi, ecc. SOAP si basa efficacemente sul set di funzionalità XML fornendo un modo standardizzato per descrivere i tuoi servizi web ( ad es. tipi e operazioni) tramite un WSDL. La verbosità e la complessità delle specifiche WSDL significano che può essere più noioso da sviluppare ma allo stesso tempo ci sono molti più strumenti disponibili per te e la maggior parte dei linguaggi moderni forniscono strumenti automatizzati per generare i proxy dei tuoi clienti prendendo un po 'del peso spento quando si tenta di interagire con servizi esterni.
Consiglio comunque di utilizzare XML per i tuoi servizi web se disponi di un "servizio aziendale" ben definito che non è soggetto a frequenti cambiamenti o se è necessario accedere al tuo servizio Web da molte lingue diverse.
Per tutti i suoi vantaggi, XML ha anche degli svantaggi. Si basa su spazi dei nomi per fornire un formato estensibile tipizzato e consente di specificare attributi ed elementi all'interno dello stesso documento. Avere spazi dei nomi diversi all'interno di un unico documento significa molto tempo quando si utilizza un parser Xml per estrarre i dati, sarà inoltre necessario fornire lo spazio dei nomi di ciascun elemento che si desidera recuperare / attraversare. Estrapola anche il payload rendendolo più dettagliato di quanto debba essere. Avere l'opzione di generare attributi e elementi significa che le tue classi non si associano bene a un documento XML. Queste caratteristiche da sole lo rendono inadeguato a livello di programmazione per la maggior parte delle lingue rendendolo più noioso e ingombrante con cui lavorare.
D'altra parte JSON è l'esatto opposto di XML in molti modi in quanto è tipicamente impreciso e ha solo un supporto semplice per i tipi di base: Numero, Bool, stringa, Oggetti e array. Tutto il resto deve essenzialmente adattarsi a una stringa. Questo non è eccezionale quando si tenta di comunicare oltre i confini del linguaggio in quanto è necessario aderire ad alcune specifiche non standard fuori banda se si desidera supportare tipi più specifici. D'altro canto il suo set di funzionalità limitato si adatta perfettamente alla maggior parte dei linguaggi ed è perfettamente adatto per JavaScript poiché una stringa JSON può essere valutata direttamente nell'oggetto JavaScript.
Dimensioni e prestazioni
Ho alcuni benchmark di database northwind disponibili che confrontano le dimensioni e la velocità tra le implementazioni XML e JSON di Microsofts. Fondamentalmente l'XML è più del doppio delle dimensioni di JSON, ma allo stesso tempo sembra che Microsoft abbia fatto molti sforzi per ottimizzare il proprio XML DataContractSerializer in quanto è più del 30% più veloce di quello JSON. Sembra che tu debba fare un compromesso tra dimensione e prestazioni. Non contento di questo fatto, ho deciso di scrivere il mio veloce JsonSerializer che ora è 2,6 volte più veloce di quello XML di MS - quindi il migliore dei due mondi :).
Quando segui il percorso JSON, incontri gli stessi problemi che XML ha affrontato 10 anni fa:
La miscelazione di dati da due origini diverse in un pacchetto JSON può causare l'aggancio reciproco delle etichette degli elementi. Mescola una bolla di accompagnamento e una fattura e improvvisamente l'indirizzo del mittente può significare qualcosa di completamente diverso. Ecco perché XML ha spazi dei nomi .
La conversione tra diverse strutture JSON richiederebbe la scrittura di codice banale. Un modo più dichiarativo per mappare i dati faciliterebbe il lavoro. Ecco perché XML ha XSLT .
Descrivere la struttura di un pacchetto JSON - i suoi campi, tipi di dati, ecc. - è necessario per consentire alle persone di collegarsi ai tuoi servizi. È essenziale disporre di un linguaggio di metadati per questo. Ecco perché XML ha schemi .
È necessario eseguire due conversazioni simultanee client-server. Se poni al server due domande e ricevi una risposta, come fai a sapere a quale domanda risponde? Ecco perché XML ha una correlazione WS .
Dalla prima riga su http://json.org/xml.html
Extensible Markup Language (XML) è un formato di testo derivato dallo Standard Generalized Markup Language (SGML). Rispetto a SGML, XML è semplice. HyperText Markup Language (HTML), al confronto, è ancora più semplice. Anche così, un buon libro di consultazione su HTML ha uno spessore di un pollice. Questo perché la formattazione e la strutturazione dei documenti è un affare complicato. . . .
Chiaramente JSON è più veloce, ma è ancora più chiaro che è difficile da leggere. Usa JSON per la velocità, usa XML se ci sarà interazione umana e puoi sacrificare la velocità.
Uso JSON per qualsiasi tipo di configurazione, scambio dati o messaggistica. Uso XML solo se devo per altri motivi o per contrassegnare semanticamente dati simili a documenti.
Sia XML che JSON sono supportati da Microsoft. I letterali XML erano la nuova fantastica funzionalità di VB 9. Nella prossima versione di ASP.NET 4.0 JSON è un must per sfruttare la potenza del modello lato client.
Dalla domanda che hai posto sembra JSON potrebbe essere la scelta per te in quanto è facile da elaborare sul lato client con o senza jQuery.
Utilizzando JSON
Utilizzando XML
Ho trovato questo articolo al bazar digitale davvero interessante.
Alcune parti dell'articolo sono riportate di seguito.
Informazioni sui professionisti JSON:
Se tutto ciò che vuoi passare sono valori atomici o elenchi o hash di valori atomici, JSON ha molti dei vantaggi di XML: è facilmente utilizzabile su Internet, supporta un'ampia varietà di applicazioni, è facile scrivere programmi per elaborare JSON, ha poche funzionalità opzionali, è leggibile e ragionevolmente chiaro, il suo design è formale e conciso, i documenti JSON sono facili da creare e utilizza Unicode. ...
Informazioni sui professionisti XML:
XML si occupa notevolmente della piena ricchezza di dati non strutturati. Non sono affatto preoccupato per il futuro di XML, anche se la sua morte è celebrata allegramente da un gruppo di progettisti di API Web.
E non posso resistere a rimboccare un "Te l'ho detto!" token via nella mia scrivania. Non vedo l'ora di vedere cosa fanno le persone JSON quando viene loro chiesto di sviluppare API più ricche. Quando vogliono scambiare dati meno strutturati, li calcheranno su JSON? Vedo menzioni occasionali di un linguaggio di schema per JSON, seguiranno altre lingue? ...
Regole rapide:
Spiegazione:
L'unico ruolo di JSON è serializzare i dati orientati agli oggetti utilizzando i tipi di dati comuni alla maggior parte dei linguaggi di programmazione: elenchi , hash e scalari e, a tale scopo, non possono essere realmente battuti o migliorati. In parole povere "JSON non ha un numero di versione [poiché] non sono previste revisioni della grammatica JSON". - Douglas Crockford (non posso batterlo come un segno che fai perfettamente il tuo lavoro)
Una volta l'XML veniva venduto come formato di interscambio di dati, ma si considerano i due casi d'uso più comuni: comunicazione asincrona client-server (AJAX) - JSON ha praticamente sostituito interamente l'XML (l'X dovrebbe essere davvero una J) e i servizi web : JSON ha reso XML un'alternativa ridondante.
L'altra cosa per cui l'XML è stato ampiamente utilizzato sono stati i file di dati scrivibili / leggibili (?) Per i programmi, ma anche qui in YAML, un superset JSON è disponibile un formato più conciso, più intuitivo e più intuitivo.
Quindi, per la rappresentazione dei dati, JSON batte XML su tutta la linea. Cosa rimane quindi per XML? Rappresentazione di documenti a contenuto misto, a cui è destinato .
La maggior parte delle tecnologie web più recenti funzionano con JSON, quindi sicuramente una buona ragione per usare JSON. Un grande vantaggio è che in XML è possibile rappresentare in molti modi diversi le stesse informazioni, che in JSON è più semplice.
Anche JSON IMHO è molto più chiaro di XML, il che lo rende un chiaro vantaggio. E se lavori con .NET, Json.NET è un chiaro vincitore per aiutarti a lavorare con JSON.