Flat atau bersarang JSON untuk data hierarki?


12

Saya sudah bolak-balik ~ 5 kali sudah. Titik akhir REST ini /api/tags/akan untuk penggunaan internal (tidak ada klien pihak ke-3), saya satu-satunya yang bekerja dengannya.

Saya memutuskan antara dua representasi ini:

Datar

{  
   "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
      },
   ]
}
  • Ini agak modular. Dapat menambahkan lapisan teratas lain seperti "negara" tanpa merusak kompatibilitas.

Bersarang

{  
   "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"
         },
      }
   },
}
  • Sudah dalam format yang dapat digunakan. Tidak perlu mengulang-ulang data sebelum menggunakannya.
  • Menghemat bandwidth. Bahkan setelah gzip, ini sedikit lebih kecil.

Yang mana yang harus digunakan, dan mengapa? Jika ini adalah masalah preferensi pribadi, representasi mana yang akan disukai pengembang dan mengapa?


Is this a matter of personal preference?. Aku pikir begitu. Persyaratan> kebutuhan> preferensi
Laiv

1
@ Longv Dalam hal itu, pertanyaan saya harus diulangi "Representasi mana yang disukai pengembang berpengalaman dan mengapa?"
dvtan

Apakah id ini stabil dari waktu ke waktu dan tidak masalah bagi klien untuk mengingat dan menggunakannya nanti, atau, apakah itu hanya pesan lokal?
Erik Eidt

@ErikEidt Permanen, kunci primer basis data.
dvtan

Apakah Anda menganggap Air lebih sebagai subclass dari Utility atau lebih sebagai instance dari Utility?
Erik Eidt

Jawaban:


8

Tergantung pada kasus penggunaan Anda.

Saat menggunakan JSON dengan bahasa yang diketikkan statis, ada bonus besar jika struktur Anda memetakan ke jenis Anda. Ini berarti bahwa semua nama kunci harus diketahui sebelumnya.

Jadi, jika Anda berencana menggunakan Java untuk menggunakan layanan ini, atau jika Anda berencana untuk mendokumentasikannya dengan Skema JSON, nomor satu akan jauh lebih bersih (tentu saja keduanya akan berfungsi).


4

Sulit dikatakan tanpa lebih banyak konteks. Saya telah bekerja dengan keduanya tetapi semakin saya mulai bersandar ke # 1. Secara umum, saya telah menemukan kesederhanaan lebih relevan daripada kecanggihan.

Di # 1, entitas dan hubungan jelas dan jelas, sedangkan # 2 membutuhkan cara berpikir yang berbeda. Bagi sebagian orang, pohon (sebagai struktur data) tidak menggambarkan diri sendiri. Pikirkan pengembang junior yang hampir tidak pernah melihat komposisi | agregasi yang lebih dalam dari Person> Address .

Saya bisa membaca # 1 sebagai:

  • ada koleksi tag yang diketik .

Tapi, bagaimana kita bisa menggambarkan # 2 hanya dalam 7 kata? Jika saya tidak terbiasa dengan struktur pohon saya bisa membaca # 2 sebagai

  • tag memiliki dua atribut 5 dan 17, tetapi saya tidak tahu tipenya. Apa pun jenisnya, memiliki satu atribut, teks .

Jangan salah paham, # 2 bisa menjadi solusi cerdas, tapi saya tidak akan mengorbankan keterbacaan untuk kepintaran (atau efisiensi) tanpa perlu.

Pada penulisan jawaban ini, saya sedang mengerjakan sebuah proyek yang perlu diintegrasikan dengan layanan pihak ke-3 yang responsnya sangat mirip dengan # 2. Layanan ini memberi kami kalender: tahun, bulan, hari, dan jam sehari

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

Sebagai pengembang Java, deserialisasi respons layanan berakhir dengan kode yang sama sekali tidak dapat dibaca karena tidak ada pemetaan langsung ke kelas melalui getter | setter | konstruktor. Sebaliknya, saya harus melintasi dokumen ( getNode, getSiblings, getNodeName, getChildAsText, isNodeObject, isText, dll) dan mengisi hirarki kelas saya secara manual. Akhirnya, saya berhasil memetakan pohon angka ke dalam koleksi cap waktu! Struktur mana yang menurut Anda lebih mudah dibaca dan deserialise? Dan yang mana yang ingin Anda dapatkan jika Anda berada di sisi klien?


1

Jika Anda tidak menginginkan yang lain, Anda bisa menggunakan:

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

Sayangnya di sini JSON hanya mengizinkan string sebagai kunci.


Atau berpotensi "Utility": ["Water","Electricity"]dll
Caleth

Tetapi kemudian Anda tidak dapat referensi mereka. Saya berharap semua ini diikuti oleh sebuah array yang menggambarkan ribuan rumah, dan masing-masing berisi misalnya "8", "9", "5".
gnasher729
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.