API REST - API có nên trả về các đối tượng JSON lồng nhau không?

Khi nói đến API JSON, cách tốt nhất là làm phẳng các phản hồi và tránh các đối tượng JSON lồng nhau?

Như một ví dụ cho phép chúng ta có một API tương tự IMDb nhưng dành cho các trò chơi video. Có một vài thực thể, Trò chơi, Nền tảng, ESRBRating và GamePl PlatformMap để ánh xạ Trò chơi và Nền tảng.

Hãy nói rằng bạn yêu cầu / trò chơi / 1 tìm nạp trò chơi bằng ID 1 và nó trả về đối tượng trò chơi với các nền tảng và esrbRating lồng nhau.

{
  "id": 1,
  "title": "Game A",
  "publisher": "Publisher ABC",
  "developer": "Developer DEF",
  "releaseDate": "2015-01-01",
  "platforms": [
    {"id":1,"name":"Xbox"},
    {"id":2,"name":"Playstation"}
  ],
  "esrbRating": {
    "id": 1,
    "code": "E",
    "name": "Everyone"
  }
}

Nếu bạn đang sử dụng một cái gì đó như JPA / Hibernate, nó có thể tự động làm điều này cho bạn nếu nó được đặt thành FETCH.EAGER.

Tùy chọn khác là chỉ đơn giản là API và thêm nhiều điểm kết thúc.

Trong trường hợp đó khi / game / 1 được yêu cầu, đối tượng trò chơi được trả về.

{
  "id": 1,
  "title": "Game A",
  "publisher": "Publisher ABC",
  "developer": "Developer DEF",
  "releaseDate": "2015-01-01",
}

Nếu bạn muốn các nền tảng và / hoặc ESRBRating, bạn sẽ phải gọi như sau:

/ trò chơi / 1 / nền tảng / trò chơi / 1 / esrb

Phương pháp này có vẻ như có khả năng có thể thêm nhiều cuộc gọi đến máy chủ tùy thuộc vào dữ liệu nào khách hàng cần và khi nào họ cần.

Có một suy nghĩ cuối cùng tôi đã có nơi bạn sẽ có một cái gì đó như thế này trở lại.

{
  "id": 1,
  "title": "Game A",
  "publisher": "Publisher ABC",
  "developer": "Developer DEF",
  "releaseDate": "2015-01-01",
  "platforms": ["Xbox","Playstation"]
}

Tuy nhiên, điều này giả định rằng họ không cần ID hoặc bất kỳ thông tin nào khác có thể được liên kết với các đối tượng nền tảng đó.

Nói chung, tôi hỏi cách tốt nhất để cấu trúc các đối tượng JSON được trả về từ API của bạn là gì. Bạn có nên cố gắng ở gần các thực thể của mình nhất có thể không, hoặc sử dụng Đối tượng miền hoặc Đối tượng truyền dữ liệu có ổn không? Tôi hiểu các phương thức sẽ có sự đánh đổi, hoặc nhiều công việc hơn trên lớp truy cập dữ liệu hoặc nhiều công việc hơn cho khách hàng.

Tôi cũng muốn nghe câu trả lời liên quan đến việc sử dụng Spring MVC làm công nghệ phụ trợ cho API, với JPA / Hibernate hoặc MyBatis để duy trì.

Một cách khác (sử dụng HATEOAS). Điều này rất đơn giản, chủ yếu là trong thực tế, bạn thêm một thẻ liên kết trong json tùy thuộc vào việc bạn sử dụng HATEOAS.

http://api.example.com/games/1:

{
  "id": 1,
  "title": "Game A",
  "publisher": "Publisher ABC",
  "developer": "Developer DEF",
  "releaseDate": "2015-01-01",
  "platforms": [
    {"_self": "http://api.example.com/games/1/platforms/53", "name": "Playstation"},
    {"_self": "http://api.example.com/games/1/platforms/34", "name": "Xbox"},
  ]
}

http://api.example.com/games/1/platforms/34:

{
  "id": 34,
  "title": "Xbox",
  "publisher": "Microsoft",
  "releaseDate": "2015-01-01",
  "testReport": "http://api.example.com/games/1/platforms/34/reports/84848.pdf",
  "forms": [
    {"type": "edit", "fields: [] },
  ]
}

Tất nhiên bạn có thể nhúng tất cả dữ liệu vào tất cả các danh sách nhưng điều đó có thể sẽ là quá nhiều dữ liệu. Bằng cách này, bạn có thể nhúng dữ liệu cần thiết và sau đó tải thêm nếu bạn thực sự muốn làm việc với nó.

Việc thực hiện kỹ thuật có thể chứa bộ nhớ đệm. Bạn có thể lưu trữ các liên kết và tên nền tảng trong đối tượng trò chơi và gửi nó ngay lập tức mà không cần phải tải api nền tảng. Sau đó khi cần bạn có thể tải nó.

Bạn thấy ví dụ tôi đã thêm một số thông tin mẫu. Tôi đã làm điều đó để cho bạn thấy có thể có nhiều thông tin hơn trong một đối tượng json chi tiết hơn là bạn thậm chí muốn tải trong danh sách các trò chơi.

Đây là một trong những câu hỏi cơ bản khi nói đến thiết kế API REST. Mỗi nhà thiết kế tự hỏi mình câu hỏi này vào ngày đầu tiên. Xin lỗi nhưng câu trả lời là "nó phụ thuộc". Mỗi cách tiếp cận đều có ưu và nhược điểm và bạn sẽ chỉ cần đưa ra quyết định và đi theo nó.

Tôi thứ hai cách tiếp cận được trình bày ở đây https://www.sl slideshoware.net/stormpath/rest-jsonapis

Nói tóm lại, bao gồm tài nguyên lồng nhau dưới dạng liên kết trong tài nguyên gốc, trong khi đó, cung cấp một tham số mở rộng trong điểm cuối cha.

Theo tôi, đây là một cách hiệu quả và linh hoạt trong hầu hết các trường hợp.