RESTful 语法。是 Eager/Lazy 还是两者兼而有之？
RESTful syntax. Is it Eager/Lazy or both?
我正在尝试遵循 RESTful 原则，但对如何设置 "Eager" 或 "Lazy" 端点有些困惑。
例如，
商店有很多产品
产品有很多成分。
产品有多种包装
当然，一个 "bad" 会急切获取的端点是：
api/shop/1
会 return shop id 1 的详细信息 而且还有：
全部 产品
全部 产品的成分
所有产品的包装
这当然是一个疯狂的模型...所以我只能猜测 RESTful 默认情况下是 "always lazy"？
但是 "lazy be default" 假设您想获得 10 种不同的产品及其成分...
api/shop/1/product/1/ingredients
api/shop/1/product/2/ingredients
api/shop/1/product/3/ingredients
请求的数量有点高...10 个产品的 10 个单独的 HTTP 请求。
那么最后，您是否倾向于根据 front-end/consumer 的需求来设计 RESTful 端点，而不是对 business/database 进行建模？
api/shop/1/product-details?productId=1,2,3,4,5,6,7,8,9,10
以上是严格的"RESTful"吗？
所以我想真正的根本问题是：
RESTful API 设计数据模型还是视图模型？
Is RESTful API design a model of the Data or a model of the Views?
浏览量更近——资源的典范
Your data model is not your object model is not your resource model is not your affordance model. -- Amundsen
最简单的类比是查看 HTML 页面中的 java 脚本
- 我们可以在 HTML 页面中嵌入 java 脚本
- 我们可以从 HTML 页面 link 到 java 脚本。
这两种方法都有效 - 它们有不同的取舍，主要是缓存的工作方式。
粗粒度资源有点类似于data transfer objects；在单个 request/response 中交换大型表示，然后客户端可以使用该表示做很多不同的事情。
细粒度的资源让您可以更好地控制缓存策略（不同的部分可以在不同的时间过期），并且可能更好地响应我们期望客户端发回这些资源的编辑表示的场景。
细粒度资源的一个问题是往返的额外负担。 HTTP/2 改进了这个故事，因为 server push 可用于将多个资源的表示链接到单个响应上——所有细粒度资源都可以在单个突发中发送。
但即便如此，我们谈论的是识别资源，而不是数据库实体。
这是关于某个问题的网页的标识符
https://api.stackexchange.com/2.2/questions/57420131?site=Whosebug
那是描述相同问题的不同资源。
REST API 与通过 HTTP 公开您的数据模型无关，它们与交换文档有关，以便客户端可以浏览完成有用工作的协议。参见 Webber 2011。
我正在尝试遵循 RESTful 原则，但对如何设置 "Eager" 或 "Lazy" 端点有些困惑。
例如，
商店有很多产品
产品有很多成分。
产品有多种包装
当然，一个 "bad" 会急切获取的端点是：
api/shop/1
会 return shop id 1 的详细信息 而且还有：
全部 产品
全部 产品的成分
所有产品的包装
这当然是一个疯狂的模型...所以我只能猜测 RESTful 默认情况下是 "always lazy"？
但是 "lazy be default" 假设您想获得 10 种不同的产品及其成分...
api/shop/1/product/1/ingredients
api/shop/1/product/2/ingredients
api/shop/1/product/3/ingredients
请求的数量有点高...10 个产品的 10 个单独的 HTTP 请求。
那么最后，您是否倾向于根据 front-end/consumer 的需求来设计 RESTful 端点，而不是对 business/database 进行建模？
api/shop/1/product-details?productId=1,2,3,4,5,6,7,8,9,10
以上是严格的"RESTful"吗？
所以我想真正的根本问题是：
RESTful API 设计数据模型还是视图模型？
Is RESTful API design a model of the Data or a model of the Views?
浏览量更近——资源的典范
Your data model is not your object model is not your resource model is not your affordance model. -- Amundsen
最简单的类比是查看 HTML 页面中的 java 脚本
- 我们可以在 HTML 页面中嵌入 java 脚本
- 我们可以从 HTML 页面 link 到 java 脚本。
这两种方法都有效 - 它们有不同的取舍，主要是缓存的工作方式。
粗粒度资源有点类似于data transfer objects；在单个 request/response 中交换大型表示，然后客户端可以使用该表示做很多不同的事情。
细粒度的资源让您可以更好地控制缓存策略（不同的部分可以在不同的时间过期），并且可能更好地响应我们期望客户端发回这些资源的编辑表示的场景。
细粒度资源的一个问题是往返的额外负担。 HTTP/2 改进了这个故事，因为 server push 可用于将多个资源的表示链接到单个响应上——所有细粒度资源都可以在单个突发中发送。
但即便如此，我们谈论的是识别资源，而不是数据库实体。
这是关于某个问题的网页的标识符
https://api.stackexchange.com/2.2/questions/57420131?site=Whosebug
那是描述相同问题的不同资源。
REST API 与通过 HTTP 公开您的数据模型无关，它们与交换文档有关，以便客户端可以浏览完成有用工作的协议。参见 Webber 2011。