¿Qué estructura JSON usar para pares de valores clave?


23

¿Qué formato JSON es una mejor opción para pares de valores clave y por qué?

[{"key1": "value1"}, {"key2": "value2"}]

O:

[{"Name": "key1", "Value": "value1"}, {"Name": "key2", "Value": "value2"}]

O:

{"key1": "value1", "key2": "value2"}

La primera variante parece más compacta y más "semánticamente significativa". La segunda variante parece más uniformemente estructurada, lo que podría ayudar a procesarla. La tercera variante parece aún más semántica.

Los pares de valores clave se utilizarán para adjuntar datos arbitrarios a algún otro elemento. Los datos deben ser serializados como JSON para darles la vuelta a través de un sistema.


3
A menos que requiera un pedido, ¿por qué no considerarlo {"key1": "value1", "key2": "value2"}?
kennytm

44
JSON ya es un diccionario (anidable).
Kasey Speakman

1
Su problema es que la descripción es lo suficientemente amplia como para decir que cualquiera de esos formatos funcionará, y la verdadera pregunta es cómo simplificar su consumo, lo que depende de las tecnologías que utilicen los clientes.
scriptin

Debe usar el más simple que satisfaga sus necesidades, con suerte, será la forma de objeto simple (# 3). Sin embargo, si está buscando aún más opciones, puede usar dos matrices en paralelo, una para las claves y otra para los valores; eso será lo más compacto posible mientras se sigan admitiendo claves de objeto y claves duplicadas (que no serían compatibles con el n. ° 3).
Erik Eidt

Respuestas:


10

Si elige la primera o la tercera opción depende de su caso de uso. Si está modelando muchas instancias diferentes del mismo tipo de cosas, elija la primera. Por ejemplo, tienes una lista de personas. Si está modelando muchos atributos diferentes de una cosa, elija la tercera. Puede tener claves repetidas en el primer formato, pero no en el tercero.

La segunda opción es terrible, y aún no he encontrado un caso de uso adecuado para ello. La razón por la que es terrible, además de ser más detallado, es que para JSON de un solo nivel, rompe la conversión automática de la mayoría de las bibliotecas a un diccionario / mapa. Para JSON profundamente anidado, rompe la interfaz de consulta tipo XPath .

Esto dificulta trabajar con él. Y si no conoce sus claves en el momento de la compilación, querrá un diccionario o una interfaz XPath, porque no podrá convertirlo en una clase. Puede que ahora no parezca un gran problema, pero cuanto más tiempo tenga un formato de datos, más difícil será cambiarlo.


55
La gran ventaja de la segunda opción es que funciona con teclas que no son cadenas, en particular las teclas compuestas.
CodesInChaos

1
¿La segunda opción es terrible y aún no has encontrado un caso de uso? La matriz de diccionarios con muchos pares clave / valor debe ser sobre el formato más común para transmitir múltiples objetos.
gnasher729

2
@ gnasher729, en su caso, "la mayoría formato común" las verdaderas claves están en el lado de la izquierda: [{"key1": "value1", "key2": "value2"}]. El segundo formato aquí es colocar la clave real en el lado derecho y usar otra clave llamada "Nombre" para señalar la clave real, lo que hace que sea extremadamente difícil de analizar con herramientas estándar.
Karl Bielefeldt

Te lo daré, @CodesInChaos. Incluso allí, sin embargo, tendría que ser un caso muy especial. Nunca he visto la necesidad en la naturaleza.
Karl Bielefeldt

3
Lo siento, pero esta es una mala respuesta. La segunda opción es muy utilizada y recomendada. Permite flexibilidad de claves, permite la extensión (con más campos de valor / metadatos) sin romper los consumidores, y puede preservar el orden de los elementos. Además, las razones dadas son falsas: no interrumpe ninguna "conversión automática" (simplemente respeta la presentación del autor como matriz) y funciona bien con una interfaz de consulta similar a XPath. El único inconveniente es la mayor verbosidad.
Hejazzman

5

El 3er formato es en general el mejor. Sin embargo, aquí hay un ejemplo de algo adecuado para el primer formato:

[{
  "username": "foo",
  "id": 1
}, {
  "username": "bar",
  "id": 2
}, {
  "username": "baz",
  "id": 3
}]

Aquí cada objeto se refiere a una cosa separada (y cada objeto usa las mismas teclas que los demás, por lo que no se pueden fusionar). Sin embargo, cada objeto en la lista se almacena en { "username": "foo", "id": 1 }lugar de [{ "username": "foo" }, { "id": 1 }]porque 1) es más corto y 2) se refiere a una cosa con un nombre de usuario y una identificación, no una cosa con un nombre de usuario y otra cosa con una identificación.

El problema con la segunda opción es que se vuelve muy detallado tanto como JSON como para trabajar con él. Sin embargo, podría usarse si necesita almacenar metainformación sobre la propiedad. Un ejemplo:

{
  "key": "foo",
  "value": 1,
  "mutable": true
}

Aquí se mutablerefiere a un caso hipotético de si puede modificar la propiedad en sí, no el objeto primario. La metainformación como esta es similar a la de JavaScript Object.defineProperty, que almacena información "configurable", "enumerable" y "grabable" sobre una propiedad.


Estaba tratando de usar el primer formato para algunos JSON que estaba enviando a un punto final C # REST y no se estaba convirtiendo en un objeto de diccionario. Al convertirlo al 3er formato se borró eso.
fizch

5

Dices que estos son pares clave / valor. En ese caso, use # 3: diccionario de pares clave / valor.

Si no se trata de pares clave / valor, no los llame "claves" y "valores" y use el # 2, una matriz de diccionarios con contenido arbitrario.

La Estructura n. ° 1 es una tontería a menos que necesite pares clave / valor, pero también su orden. Lo cual rara vez haces.


3

Ponte en el lugar de la persona que recibe el json. Si no sé el nombre de la clave, ¿cómo se supone que debo recuperarlo con el primer o el último formato? Puede recorrer el json, por supuesto, pero dado que los tres formatos logran el mismo resultado, es solo una cuestión de sintaxis. Creo que esta es la única pregunta significativa: si conoce los nombres clave, la primera o la última opción son más compactas, si no, la segunda opción es más comprensible.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.