6

考虑具有名称和多个位置 (/users/{id}/locations) 的用户 (/users/{id})。

当我请求一个用户 (/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 以获取他们真正想要的所有数据更好。

4

3 回答 3

3

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

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

Jim Webber、Savas Parastatidis 和 Ian Robinson 有一篇关于 HATEOAS 的好文章，名为“如何喝杯咖啡”

于 2012-05-02T12:30:47.907 回答
2

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

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

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

于 2012-05-02T00:48:30.460 回答
1

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

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

{ "id":123, "name":"Peter", "locations":"/users/123/locations" }
于 2012-05-02T04:15:21.287 回答