JSON phẳng hoặc lồng nhau cho dữ liệu phân cấp?

Tôi đã chuyển đổi qua lại ~ 5 lần rồi. Điểm cuối REST này /api/tags/sẽ được sử dụng nội bộ (không có ứng dụng khách bên thứ 3), tôi là người duy nhất làm việc với nó.

Tôi quyết định giữa hai đại diện này:

Bằng phẳng

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

• Nó hơi mô-đun. Có thể thêm một lớp trên cùng như "quốc gia" mà không phá vỡ tính tương thích.

Lồng nhau

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

• Nó đã ở định dạng có thể sử dụng. Đừng cần lặp qua dữ liệu trước khi sử dụng nó.
• Tiết kiệm một số băng thông. Ngay cả sau gzip, cái này nhỏ hơn một chút.

Cái nào nên dùng, và tại sao? Nếu đây là vấn đề sở thích cá nhân, đại diện nào các nhà phát triển có kinh nghiệm sẽ thích và tại sao?

Phụ thuộc vào trường hợp sử dụng của bạn.

Khi sử dụng JSON với các ngôn ngữ được nhập tĩnh, sẽ có một phần thưởng rất lớn nếu cấu trúc của bạn ánh xạ tới các loại của bạn. Điều này có nghĩa là tất cả tên của các khóa nên được biết trước.

Vì vậy, nếu bạn có kế hoạch sử dụng Java để sử dụng dịch vụ hoặc nếu bạn dự định làm tài liệu với Lược đồ JSON, thì số một sẽ sạch hơn nhiều (tất nhiên cả hai sẽ hoạt động).

Khó nói mà không có thêm bối cảnh. Tôi đã làm việc với cả hai nhưng dần dần tôi bắt đầu nghiêng về # 1. Nói chung, tôi đã tìm thấy sự đơn giản có liên quan nhiều hơn sự tinh tế.

Trong # 1, các thực thể và mối quan hệ rõ ràng và rõ ràng, trong khi # 2 đòi hỏi một cách suy nghĩ khác. Đối với một số người, cây (dưới dạng cấu trúc dữ liệu) không phải là tự mô tả. Hãy suy nghĩ trong các nhà phát triển cơ sở, những người hầu như chưa thấy một thành phần | tổng hợp sâu hơn Người> Địa chỉ .

Tôi có thể đọc # 1 là:

• có một bộ sưu tập các thẻ đánh máy .

Nhưng, làm thế nào chúng ta có thể mô tả # 2 chỉ trong 7 từ? Nếu tôi không quen thuộc với cấu trúc cây, tôi có thể đọc # 2 là

• các thẻ có hai thuộc tính 5 và 17, nhưng tôi không biết loại của chúng. Dù loại này là gì, có một thuộc tính, văn bản .

Đừng hiểu sai ý tôi, # 2 có thể là một giải pháp thông minh, nhưng tôi sẽ không hy sinh khả năng đọc cho sự thông minh (hoặc hiệu quả) một cách không cần thiết.

Khi viết câu trả lời này, tôi đang thực hiện một dự án cần được tích hợp với dịch vụ của bên thứ 3, câu trả lời rất giống với # 2. Dịch vụ này cung cấp cho chúng tôi lịch: năm, tháng, ngày và giờ trong ngày

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

Với tư cách là nhà phát triển Java, việc giải tuần tự hóa đáp ứng dịch vụ kết thúc bằng mã có thể đọc được vì không có ánh xạ trực tiếp tới các lớp thông qua getters | setters | constructor. Thay vào đó, tôi đã phải duyệt qua tài liệu ( getNode, getSiblings, getNodeName, getChildAsText, isNodeObject, isText, v.v.) và điền vào hệ thống phân cấp các lớp của tôi theo cách thủ công. Cuối cùng, tôi quản lý để ánh xạ cây số vào một bộ dấu thời gian! Cấu trúc nào bạn muốn nói là dễ đọc và giải thích hơn? Và cái nào bạn muốn nhận nếu bạn ở phía khách hàng?

Nếu bạn không muốn bất cứ điều gì khác, bạn chỉ có thể sử dụng:

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

Thật không may ở đây là JSON chỉ cho phép các chuỗi làm khóa.