【问题标题】：Thin or thick REST-client?瘦还是厚 REST 客户端？
【发布时间】：2013-08-05 23:55:30
【问题描述】：
我们有从服务器（REST API）获取数据的移动应用程序
有两种方法：
- /v1/movies（返回电影：id、title、image_url ...）
- /v1/likes（返回用户喜欢的电影 id）
移动应用程序有一个“我的喜欢”视图，其中包含用户喜欢的电影，并且该视图还必须包含必要的元数据（id、title、image_url ...）
我看到了一些解决方案：
- 在“/likes/”方法中返回有关电影的更多信息
- 创建新方法“/movies/likes/”
- 移动应用程序应发出 2 个请求。
我知道，这是灵活性和速度之间的选择。
当应用变成瘦客户端而不是粗客户端时，边界在哪里？
【问题讨论】：
标签：
rest
web-applications
【解决方案1】：
通常，可扩展应用程序的最佳方法是发出尽可能少的 HTTP 请求。为此，您应该在为初始资源请求发送回的数据中包含有关其他资源的信息。 关键是将其他数据标记为不同的 URI，然后您的客户端可以将其缓存在不同的 URI 下。
Take a look at HAL。 HAL 提供了所请求资源的表示，以及一些元数据，其中包括它链接到的其他资源的 URI (_links)，并允许将这些其他资源的完整副本放入-符合响应 (_embedded)。
这为您提供了每个请求的最大 bang，直到我们获得允许多个请求内联的 HTTP/2.0。
我不使用术语“瘦”和“胖”客户端。每一行代码都让它稍微粗一点，两者之间没有界限。