DTO 应该代表嵌套实体结构，还是应该将我的路径设置为每个嵌套对象都有一个端点？

Posted 2023-02-19

【中文标题】DTO 应该代表嵌套实体结构，还是应该将我的路径设置为每个嵌套对象都有一个端点？

【英文标题】：Should DTOs represent nested entity strutctures, or should I have my pathing set up to have an endpoint for each nested object?

【发布时间】：2020-01-31 01:45:32

【问题描述】：

例如，假设我有一个看起来像这样的实体。

public class PersonEntity 
    public String firstName;
    public String lastName;
    public List<CarEntity> cars;

选项 1GET /people/1

    "firstName": "Bob",
    "lastName": "Sagget,
    "cars": [
        (could be just IDs or the full Car DTOs)
    ]

选项 2GET /people/1

    "firstName": "Bob",
    "lastName": "Sagget"

GET /people/1/cars

[
    
        "make": "Honda",
        "model": "Accord",
        "year": 1992
    
]

我觉得选项 2 更 RESTful。但我也想知道在每个场景中您都需要完整嵌套对象集的实例。在那种情况下我还应该这样设计吗？另外，如果 Car 实体有嵌套对象怎么办？我需要第三个端点来向下导航到汽车子实体。

【参考方案1】：

如果您将整个cars dto 放入people，您将能够在同一页面上显示一个人和该人拥有的所有汽车，我认为这是一个更用户友好的设计。

如果您为person's cars 创建单独的端点，则用户将首先导航到person's 页面，然后用户必须再次单击才能看到此person's cars甚至可能需要另一个页面加载

【讨论】：

感谢您的回答。我可能应该提到这是针对 API 而不是网站。因此，使用 API 的前端可以通过首先调用 /people/1 然后调用 /people1/cars 并加入他们身边的数据来显示用户及其所有汽车的列表。

我知道这是一个 API，我的回答是考虑到它是一个 API 的事实。您应该简单地编写两个端点 person/id 这个应该返回一个人对象和这个人拥有的汽车对象列表。而persons这个会返回一个列表persons并且这个列表中的每个person不需要有一个cars列表