JSON แบบแบนหรือซ้อนกันสำหรับข้อมูลลำดับชั้น?

ฉันสลับไปมา ~ 5 ครั้งแล้ว ปลายทาง REST นี้ที่/api/tags/จะใช้ภายใน (ไม่มีลูกค้าภายนอก) ฉันเป็นคนเดียวที่ทำงานกับมัน

ฉันกำลังตัดสินใจระหว่างตัวแทนสองคนนี้:

แบน

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

• มันเป็นแบบแยกส่วน สามารถเพิ่มเลเยอร์บนสุดอื่นเช่น "ประเทศ" โดยไม่ทำลายความเข้ากันได้

ที่ซ้อนกัน

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

• มันมีอยู่แล้วในรูปแบบที่ใช้งานได้ ไม่จำเป็นต้องวนซ้ำข้อมูลก่อนใช้งาน
• บันทึกแบนด์วิดท์บางส่วน แม้หลังจาก gzip สิ่งนี้จะเล็กกว่าเล็กน้อย

ควรใช้อันไหนและทำไม หากนี่เป็นเรื่องของความชอบส่วนตัวตัวแทนนักพัฒนาที่มีประสบการณ์จะชอบและทำไม?

ขึ้นอยู่กับกรณีการใช้งานของคุณ

เมื่อใช้ JSON กับภาษาที่พิมพ์แบบคงที่มีโบนัสมากถ้าโครงสร้างของคุณแมปกับประเภทของคุณ ซึ่งหมายความว่าควรทราบชื่อของคีย์ทั้งหมดล่วงหน้า

ดังนั้นหากคุณวางแผนที่จะใช้ Java เพื่อใช้บริการหรือหากคุณวางแผนที่จะจัดทำเอกสารด้วย JSON Schema หมายเลขหนึ่งจะสะอาดกว่ามาก (แน่นอนว่าทั้งคู่จะใช้งานได้)

ยากที่จะพูดโดยไม่มีบริบทเพิ่มเติม ฉันทำงานกับทั้งสองอย่าง แต่เริ่มค่อย ๆ โน้มตัวไปที่อันดับ 1 โดยทั่วไปแล้วฉันพบว่าความเรียบง่ายมีความเกี่ยวข้องมากกว่าความซับซ้อน

ใน # 1 เอนทิตีและความสัมพันธ์ชัดเจนและชัดเจนในขณะที่ # 2 ต้องการวิธีคิดที่แตกต่าง สำหรับบางคนต้นไม้ (เป็นโครงสร้างข้อมูล) ไม่ได้อธิบายตัวเอง คิดว่าในนักพัฒนาจูเนียร์ที่แทบจะไม่ได้เห็นองค์ประกอบ | รวมตัวลึกกว่าคน> ที่อยู่

ฉันสามารถอ่าน # 1 เป็น:

• มีคอลเลกชันของแท็กพิมพ์

แต่เราจะอธิบาย # 2 เพียง 7 คำได้อย่างไร ถ้าฉันไม่คุ้นเคยกับโครงสร้างต้นไม้ฉันสามารถอ่าน # 2 เป็น

• แท็กมีสองแอตทริบิวต์ 5 และ 17 แต่ฉันไม่ทราบประเภทของพวกเขา ไม่ว่าประเภทคือมีหนึ่งแอตทริบิวต์ข้อความ

อย่าเข้าใจฉันผิด # 2 อาจเป็นโซลูชันที่ชาญฉลาด แต่ฉันจะไม่ยอมเสียสละความสามารถในการอ่านเพื่อความฉลาด (หรือประสิทธิภาพ) โดยไม่จำเป็น

ในการเขียนคำตอบนี้ฉันกำลังทำงานในโครงการที่ต้องรวมเข้ากับบริการของบุคคลที่สามซึ่งการตอบสนองคล้ายกับ # 2 มาก บริการนี้ให้ปฏิทินกับเรา: ปีเดือนวันและชั่วโมงของวัน

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

ในฐานะนักพัฒนา Java ฉันเป็นดีซีเรียลไลเซชั่นของการตอบสนองการบริการสิ้นสุดลงในรหัสที่เป็นอะไร แต่อ่านได้เพราะไม่มีการแมปโดยตรงกับคลาสผ่าน getters | setters | constructors แต่ฉันต้องสำรวจเอกสาร ( getNode, getSiblings, getNodeName, getChildAsText, isNodeObject, isText, ฯลฯ )และเติมลำดับชั้นของชั้นเรียนด้วยตนเอง ในที่สุดฉันก็สามารถแมปต้นไม้ของตัวเลขลงในชุดของการประทับเวลา! คุณจะบอกว่าโครงสร้างใดที่อ่านง่ายกว่า และอันไหนที่คุณอยากได้ถ้าคุณอยู่ฝั่งลูกค้า?

หากคุณไม่ต้องการอะไรอีกคุณสามารถใช้:

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

โชคไม่ดีที่ JSON อนุญาตให้ใช้สตริงเป็นคีย์เท่านั้น