Hiyerarşik veriler için düz veya iç içe JSON?

Zaten ~ 5 kez ileri geri döndüm. Bu REST bitiş noktası /api/tags/dahili kullanım için olacak (3. taraf istemciler yok), onunla çalışan tek kişi benim.

Bu iki temsil arasında karar veriyorum:

Düz

{  
   "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
      },
   ]
}

• Biraz modüler. Uyumluluğu bozmadan "ülke" gibi başka bir üst katman ekleyebilir.

İçiçe

{  
   "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"
         },
      }
   },
}

• Zaten kullanılabilir bir biçimde. Kullanmadan önce veriler arasında geçiş yapmanıza gerek yoktur.
• Biraz bant genişliği tasarrufu sağlar. Gzip'ten sonra bile, bu biraz daha küçük.

Hangisi kullanılmalı ve neden? Bu kişisel tercih meselesi ise, deneyimli geliştiriciler hangi temsili tercih ederler ve neden?

Kullanım durumunuza bağlıdır.

Statica ile yazılan dillerle JSON kullanırken, yapınız türlerinizle eşleşiyorsa büyük bir bonus vardır. Bu, tuşların tüm adlarının önceden bilinmesi gerektiği anlamına gelir.

Bu nedenle, hizmeti kullanmak için Java kullanmayı planlıyorsanız veya JSON Şeması ile belgelemeyi planlıyorsanız, bir numara çok daha temiz olacaktır (elbette her ikisi de işe yarayacaktır).

Daha fazla bağlam olmadan söylemek zor. Her ikisiyle de çalıştım ama giderek # 1'e yaslanmaya başladım. Genel olarak, sadeliği sofistike olmaktan daha alakalı buldum.

# 1'de varlıklar ve ilişkiler açık ve açıktır, oysa # 2 farklı bir düşünce tarzı gerektirir. Bazı insanlar için, ağaçlar (veri yapıları olarak) o kadar tanımlayıcı değildir. Birleşme | Kişi> Adres'den daha derin bir kompozisyonu çok az gören genç geliştiricileri düşünün .

# 1 şöyle okuyabilirim:

• yazılmış etiketlerden oluşan bir koleksiyon var .

Fakat 2. kelimeyi sadece 7 kelimeyle nasıl tarif edebiliriz? Eğer ağaç yapılarına aşina olmasaydım, # 2

• Etiketler 5 ve 17 olmak üzere iki özelliğe sahiptir, ancak türlerini bilmiyorum. Tür ne olursa olsun, bir niteliğe, metne sahiptir .

Beni yanlış anlamayın, # 2 akıllı bir çözüm olabilir, ancak gereksiz yere akıllılık (veya verimlilik) için okunabilirliği feda etmem.

Bu cevabın yazımında, yanıtların # 2'ye çok benzeyen 3. taraf bir hizmetle entegre edilmesi gereken bir proje üzerinde çalışıyorum. Hizmet bize bir takvim sağlıyor: yıl, aylar, günler ve günün saatleri

 { "2017" : { "01": { "01" : ["00:00", "01:00", "02:00"] } } } 

Java geliştiricisi olarak, hizmet yanıtının serileştirilmesi, okunabilir ancak okunabilir bir şey olan kodla sonuçlandı çünkü getters | setters | yapıcıları aracılığıyla sınıflara doğrudan eşleme yok. Bunun yerine, belgeyi ( getNode, getSiblings, getNodeName, getChildAsText, isNodeObject, isText, vb.) Geçmek ve sınıflar hiyerarşisini elle doldurmak zorunda kaldım. Sonunda, sayılar ağacını bir zaman damgaları koleksiyonuna eşleştirmeyi başardım! Hangi yapının okunması ve serileştirmesinin daha kolay olduğunu söylerdiniz? Ve müşteri tarafında olsaydınız hangisini almak istersiniz?

Başka bir şey istemediyseniz, şunları kullanabilirsiniz:

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

Talihsiz burada JSON sadece anahtar olarak dizeleri izin verir.