RESTful 语法。是渴望/懒惰还是两者兼而有之？答案

【问题标题】：RESTful syntax. Is it Eager/Lazy or both?RESTful 语法。是渴望/懒惰还是两者兼而有之？
【发布时间】：2019-08-08 20:28:44
【问题描述】：

我正在尝试遵循 RESTful 原则，但对如何设置“Eager”或“Lazy”端点有点困惑。

例如，一个
商店有很多产品
产品有很多成分。
产品有多种包装

当然，会急切获取的“坏”端点是：

api/shop/1

将返回 shop id 1 的详细信息，但也会返回：
所有产品
所有产品的成分
所有产品的包装

这当然是一个疯狂的模型......所以我只能猜测 RESTful 默认是“总是懒惰的”？

但是用“懒惰是默认的”说你想得到 10 种不同的产品及其成分......

api/shop/1/product/1/ingredients
api/shop/1/product/2/ingredients
api/shop/1/product/3/ingredients

请求数量有点高...10 种产品的 10 个单独的 HTTP 请求。

最后，您是否倾向于根据前端/消费者可能想要的东西来设计 RESTful 端点，而不是对业务/数据库进行建模？

api/shop/1/product-details?productId=1,2,3,4,5,6,7,8,9,10

以上是严格的“RESTful”吗？

所以我猜真正的潜在问题是：
RESTful API 设计是数据模型还是视图模型？

【问题讨论】：

【解决方案1】：

RESTful API 设计是数据模型还是视图模型？

Views 更接近——它是一种资源模型

你的数据模型不是你的对象模型不是你的资源模型不是你的可供性模型。 -- Amundsen

最简单的类比是在 HTML 页面中查看 java 脚本

这两种方法都有效 - 它们有不同的权衡，主要是缓存的工作方式。

粗粒度资源有点类似于data transfer objects；在单个请求/响应中交换一个大的表示，然后客户端可以用那个表示做很多不同的事情。

细粒度的资源让您可以更好地控制缓存策略（不同的部分可以在不同的时间过期），并且可能更好地响应我们期望客户端发回这些资源的编辑表示的场景。

细粒度资源的一个问题是往返的额外负担。 HTTP/2 改进了这个故事，因为server push 可用于将多个资源的表示链接到单个响应中——所有细粒度的资源都可以在一次突发中发送。

但即便如此，我们谈论的是识别资源，而不是数据库实体。

https://stackoverflow.com/questions/57420131/restful-syntax-is-it-eager-lazy-or-both

这是有关问题的网页的标识符

https://api.stackexchange.com/2.2/questions/57420131?site=stackoverflow

这是描述相同问题的不同资源。

REST API 并不是要通过 HTTP 公开您的数据模型，而是要交换文档，以便客户端可以导航协议以完成有用的工作。见Webber 2011。

【讨论】：