¿JSON plano o anidado para datos jerárquicos?

7

He cambiado de un lado a otro ~ 5 veces ya. Este punto final REST en /api/tags/ será para uso interno (no clientes de terceros), soy el único que trabaja con él.

Estoy decidiendo entre estas dos representaciones:

Flat

{  
   "types":[  
      {  
         "id":1,
         "text":"Utility"
      },
      {  
         "id":7,
         "text":"Lease Terms"
      },
   ],
   "tags":[
      {  
         "id":8,
         "text":"Water",
         "type":1
      },
      {  
         "id":9,
         "text":"Electricity",
         "type":1
      },
      {  
         "id":5,
         "text":"Minimum 12 month lease",
         "type":7
      },
      {  
         "id":17,
         "text":"lease negotiable/flexible",
         "type":7
      },
   ]
}
  • Es algo modular. Puede agregar otra capa superior como "país" sin romper la compatibilidad.

Nested

{  
   "1":{  
      "text":"Utility",
      "tags":{  
         "8":{  
            "text":"Water"
         },
         "9":{  
            "text":"Electricity"
         },
      }
   },
   "2":{  
      "text":"Lease Terms",
      "tags":{  
         "5":{  
            "text":"Minimum 12 month lease"
         },
         "17":{  
            "text":"lease negotiable/flexible"
         },
      }
   },
}
  • Ya está en un formato utilizable. No es necesario recorrer los datos antes de usarlos.
  • Guarda algo de ancho de banda. Incluso después de gzip, esto es un poco más pequeño.

¿Cuál debería usarse y por qué? Si esto es una cuestión de preferencia personal, ¿qué representación preferirían los desarrolladores experimentados y por qué?

    
pregunta dtgq 10.06.2017 - 22:59

3 respuestas

5

Depende de su caso de uso.

Cuando se utiliza JSON con un lenguaje de tipo estático, hay una gran ventaja si su estructura se adapta a sus tipos. Esto significa que todos los nombres de las claves deben ser conocidos de antemano.

Entonces, si planea usar Java para consumir el servicio, o si planea documentarlo con el esquema JSON, el número uno será mucho más limpio (por supuesto, ambos funcionarán).

    
respondido por el fdreger 11.06.2017 - 10:31
2

Difícil de decir sin suficiente contexto. He trabajado con ambos formatos, pero tiendo a estructurar los datos como la opción # 1. En general, prefiero la simplicidad a la sofisticación. Si bien # 2 podría ser sinónimo de eficiencia, el primero es sinónimo de legibilidad, que creo que a menudo es una característica más relevante.

Las estructuras de datos y la relación entre ellas son obvias en la opción # 1, mientras que la segunda implica una forma diferente de pensar. Para algunas personas, las estructuras de árboles no son tan explícitamente auto-descriptivas. Piense en desarrolladores junior que apenas han visto una composición / agregación más profunda que Persona > Dirección .

Siendo simplista, pude leer el primer enfoque como:

  • hay una colección de etiquetas escritas.

Pero, ¿cómo podría describir el segundo enfoque en solo 6 palabras? Supongo que es posible, pero no es tan obvio a primera vista.

Ejemplo:

"tags":{ "5":{ "text":"Minimum 12 month lease" }, "17":{ "text":"lease negotiable/flexible" }

Si no estuviera familiarizado con JSON y las estructuras de árbol, podría leer esa estructura como:

  • las etiquetas de entidad tienen dos atributos: 5 y 17, pero no sé el tipo. Cualquiera que sea el tipo, tiene un solo atributo: texto

No me malinterpretes, la segunda opción podría ser una solución más inteligente, pero no sacrificaría la legibilidad por inteligencia o sofisticación.

Aquí usamos la expresión "Idea feliz". Una idea feliz podría tener sentido para mí y no hacerla para otros, o ser difícil de explicar.

Como dije, he trabajado con ambos enfoques. En realidad lo hago. En mi proyecto actual, tengo que integrar el backend con un servicio web de terceros cuyas respuestas son muy similares a la opción # 2. Como desarrollador de Java, estoy de acuerdo con @fdreger. La deserialización de la respuesta del servicio web es todo menos legible, ya que no existe un mapeo directo sobre getters / setters y clases. He tenido que recorrer la estructura utilizando la API del asignador: getNode, getSiblings, getNodeName, getChildAsText, isNodeObject, isText, etc ... . El servicio web nos proporciona un calendario: año, meses, días, horas del día, etc. ¡Podría administrarlo para transformar su árbol en una colección de marcas de tiempo! ¿Cuál crees que es más fácil de mapear y trabajar?

Para un lenguaje como Javascript, el mapeo es transparente y directo. Me pregunto si es también para Python. Sé que OOP es opcional en Python y tal vez hace que el lenguaje sea mucho menos tipificado y flexible, como Javascript.

Sin embargo, diseñar una estructura de datos sobre las capacidades de lenguaje es de alguna manera una forma de exponer los detalles de la implementación y condicionar la integración a idiomas con estas capacidades específicas.

    
respondido por el Laiv 11.06.2017 - 15:35
0

Si no quieres nada más, puedes usar:

{
    "Utility": {
        "8": "Water",
        "9": "Electricity"
     },
     "Lease Terms": {
        "5": "Minimum 12 month lease",
        "17": "lease negotiable/flexible"
     }
}

Aquí es desafortunado que JSON solo permita cadenas como claves.

    
respondido por el gnasher729 11.06.2017 - 17:54

Lea otras preguntas en las etiquetas