在 RESTful Web 服务中，响应 DTO 是否应该包含其子 DTO？

Question

假设一个用户 (/users/{id}) 有一个名称和多个位置 (/users/{id}/locations)。

当我请求用户 (/user/{id}) 时，应该完整地表示该用户（其 ID、名称和位置）还是应该仅在单独的请求中返回位置？例如，对于 id=123 (/users/123) 的用户的请求，您希望使用哪个 JSON DTO：

1) { "id":123, "name":"Peter", "locations":[{"id":1, "name":"Chicago"}, {"id":2, "name ":"纽约"}] }

2) { "id":123, "name":"Peter", "locations":[{"id":1}, {"id":2}] }

3) { "id":123, "name":"Peter", "locations":[1, 2] }

4) { "id":123, "name":"Peter" }

这是否更主观，在 DTO 的大小和典型用例中所需的请求之间推拉？我倾向于简单地包含所有相关数据 (1)，但我不确定这是否比仅要求开发人员多次调用 API 以获取他们实际的所有数据更好想要。

Answer 1

要成为 RESTful，您不一定必须返回资源的完整表示 但是，您确实希望启用超媒体来获取/设置 API 用户所需的所有信息（超媒体作为应用程序状态的引擎 - 又名 HATEOAS）

为了满足您的要求，您可以使用@bowmanb 的建议为所有位置放置一个 URI，或者为每个位置添加单独的 URI。您可能希望为使用资源执行某些操作的其他选项添加额外的 URI。

Jim Webber、Savas Parastatidis 和 Ian Robinson 撰写了一篇关于 HATEOAS 的好文章，名为 "how to GET a cup of coffee"

Answer 2

我是这个世界的新手，但我正在构建一个宁静的 api 并面临完全相同的问题。我最初的工作是包括所有内容 - 所以我的结果看起来像你的选择 (1)。事实上，我更进一步，在每个对象中包含一个 URI，这样理论上，响应可以由足够智能的客户端导航。

话虽如此，我发现与您的“用户”对象等效的一个特定属性是巨大的。它似乎不会影响性能，但在我看来，没有客户想要关于该特定属性的所有信息——大多数客户只想要 id 和 name。因此，我将修改该属性的默认方法。

底线 - 在我的新手看来 - 决定是由您的客户的预期使用情况驱动的 - 客户希望看到什么？

Answer 3

客户端应该有某种方法来确定如何查找用户的位置。所以我会排除第 4 个。

如果您担心响应的大小，我相信仅包含用户位置的 URI 仍然是 RESTful：

{ "id":123, "name":"Peter", "locations":"/users/123/locations" }