Sto cercando di mantenere e recuperare una grande quantità di dati di tipo chiave-valore sul cavo. È appropriato per me utilizzare JSON per questo scopo contro XML?JSON in applicazioni non Javascript
JSON è utilizzato in applicazioni non Javascript?
Ci sono vantaggi che utilizzano JSON per questo scopo rispetto al buon vecchio XML?
JSON va bene per questo utilizzo e sarà più compatto di XML. (Lo utilizziamo estensivamente in un'applicazione non Javascript e consente agli utenti dei nostri servizi Web REST di specificare se desiderano i dati nelle rappresentazioni XML, JSON o XHTML.)
Aggiornamento: dove la larghezza di banda è un preoccupazione, probabilmente si può ottenere una compressione del 50-70% mediante codifica/decodifica GZIP di XML o JSON. Vedi GZipStream.
Trovo JSON meno dettagliato di XML e vi è un database molto bello in fase di sviluppo chiamato CouchDB che consente di archiviare/cercare documenti JSON direttamente.
Naturalmente, infatti JSON è molto meglio di XML, per i seguenti motivi:
In generale le persone dovrebbero usare JSON e Pacchetti XML per la lettura (analisi) e la scrittura. I linguaggi di programmazione più recenti hanno il supporto integrato (vedi @ Michael Dillon). –
Non ho mai inteso dire che si dovrebbe scrivere il proprio parser json, anche se non è una pessima idea. – hasen
JSON non è sempre migliore di XML, a seconda di cosa ti serve. Se voglio fare più elaborazioni sul file, XML è migliore, ma se ho finito con l'elaborazione e mi sto preparando a visualizzarlo, allora JSON è fantastico. –
Perché JSON è ampiamente utilizzato dai server di applicazioni Web per comunicare con javascript nel browser (AJAX) ci sono un sacco di JSON librerie di codifica/decodifica per ogni lingua che si possa immaginare. Ad esempio Python ha 6 diverse implementazioni tra cui scegliere.
Il vantaggio principale dell'utilizzo di JSON per una "grande quantità" di dati è che il tempo di analisi per la decodifica dei dati è un po 'inferiore all'analisi dell'XML. Ora è possibile che le coppie chiave-valore siano abbastanza semplici da consentire al tempo di analisi di non fare la differenza, ma se i valori hanno qualsiasi tipo di oggetti compositi in essi, allora JSON sarà più veloce.
IMO, se si desidera mantenere le cose e si desidera avere la possibilità di aggiornare l'applicazione (che è praticamente sempre il caso), è necessario creare manualmente il codice di serializzazione e creare un formato di file documentato. Altrimenti, a un certo punto ti troverai in difficoltà.
Concordo con gli altri sull'usabilità di JSON, ma con un avvertimento: JSON non consente di fornire ulteriori informazioni sui dati. Se tutto quello che vuoi usare è coppie nome-valore, dove tutti i valori sono stringhe, JSON va bene.
OK, qualcuno probabilmente mi ha appena votato perché lo JSON spec distingue tra stringhe, numeri, booleani e matrici. Ma la mia risposta è: che tipo di numero ottieni? Un numero intero a 32 bit o un numero a virgola mobile di migliaia di cifre?
XML, in confronto, consente di memorizzare i metadati negli attributi.Ad esempio, l'attributo xsi:type, come definito da XML Schema. Entrambe le parti devono ancora concordare sul significato degli attributi, naturalmente, ma ci sono molti casi in cui i metadati sono importanti.
È anche possibile memorizzare i metadati in JSON. Proprio come esiste uno schema XML, esiste uno [schema JSON] (http://json-schema.org/). Inoltre, i numeri in JavaScript come duplicati firmati a 64 bit. –
@Elijah - (1) Uno schema, XML o JSON, è esterno ai dati, quindi non stai fornendo metadati * in * JSON. (2) Le specifiche JSON non dicono assolutamente nulla sull'intervallo di un valore numerico, e l'OP ha chiesto degli usi al di fuori di JavaScript, quindi il tuo punto sui numeri JavaScript è discutibile. – kdgregory
XSL-FO. Questo è tutto. – Incognito
Se è il meglio per voi dipenderà dalle vostre priorità, come velocità o flessibilità.
Avevo spostato un'applicazione C# per utilizzare JSON perché la velocità era il problema più importante per me. Vorrei serializzare i dati sul server e rimuovere tutto ciò che è ridondante, come il nome di ogni proprietà, al fine di accelerare il mio trasferimento, e ho trovato il tempo per inviare una richiesta al server, ottenere la risposta e il processo è stato più veloce con JSON che usare un webservice o restituire XML.
Per deserializzare, da C#, sono disponibili diverse opzioni su http://json.org.
Quindi, prima di decidere di apportare la modifica, è necessario disporre di alcuni test unitari e quindi ottenere alcuni numeri, rendendo lo stesso client -> server -> chiamata client circa 100 volte, per ottenere risultati migliori.
Si dovrebbero avere tutti i test nella stessa classe di test in modo che i test possano essere eseguiti direttamente, per ridurre la possibilità che il carico del server si verifichi.
Se è necessaria la flessibilità di ordinamento o elaborazione in altri modi, ad esempio l'utilizzo di XML LINQ, è possibile convertire le informazioni in un elenco e utilizzare LINQ, ma, ancora, è possibile aggiungere test per vedere cosa l'impatto di questo sarebbe, sulla vostra applicazione.
Fondamentalmente, credo che se si ha tempo, prima di effettuare prima qualsiasi test di modifica dell'architettura, e poi decidere se effettuare la modifica ha senso, in base ai numeri.
È più compatto di XML e in alcuni casi è più veloce da analizzare. Quindi normalmente lo preferisco.
D'altra parte, XML risolve alcuni problemi specifici fornendo soluzioni (per esempio codifiche).
Tuttavia, posso semplicemente scrivere nella mia specifica "È necessario solo utilizzare UTF-8" e quindi il problema delle specifiche di codifica è risolto.
In pratica, è possibile utilizzare JSON se si ha bisogno di una chiave/valore semplice o di una chiave nidificata/valore/struttura elenco e si desidera risolvere i problemi comuni di escaping e delimitamento, con molti parser disponibili.
ho scritto almeno un protocollo utilizzando JSON, e gli utenti del non si è mai lamentato di usare JSON invece di XML, pur essendo su Microsoft.NET :)
Giusto per essere chiari, JSON e XML hanno i loro punti di forza e debolezze. Cose come la XSL sono davvero fantastiche, ma c'è molto lavoro da fare. Non sono "la stessa cosa" (sto solo facendo questo stop per essere vocale, so che molte persone non capiscono cosa fa XML e dicono "hey JSON è più semplice") – Incognito