rest - 瘦还是厚 REST 客户端？

Question

我们有从服务器获取数据的移动应用程序（REST API）

有两种方法：

• /v1/movies（返回电影：id、title、image_url ...）
• /v1/likes（返回用户喜欢的电影 id）

移动应用程序有一个“我的喜欢”视图，其中包含用户喜欢的电影，并且该视图还必须包含必要的元数据（id、title、image_url ...）

我看到了一些解决方案：

1. 在“/likes/”方法中返回有关电影的更多信息
2. 创建新方法“/movies/likes/”
3. 移动应用程序应发出 2 个请求。

我知道，这是灵活性和速度之间的选择。当应用程序变成瘦客户端而不是厚客户端时，边界在哪里？

Answer 1

通常，可扩展应用程序的最佳方法是发出尽可能少的 HTTP 请求。为此，您应该在为初始资源请求发送回的数据中包含有关其他资源的信息。关键是将其他数据标记为不同的 URI，然后您的客户端可以将其缓存在不同的 URI 下。

看看 HAL。HAL 提供了所请求资源的表示，以及一些元数据，其中包括它链接到的其他资源的 URI ( _links)，并允许将这些其他资源的完整副本与响应 ( _embedded) 内联。

这为您提供了每个请求的最大效果，直到我们获得允许多个请求内联的 HTTP/2.0。

我不使用术语“瘦”和“厚”客户端。每一行代码都让它稍微粗一点，两者之间没有界限。