REST API关系，使用SQL连接以模块化方式（多个请求）和聚合（单个请求）获取的优缺点

Question

通常从我看到的REST API以模块化方式实现。 例如，假设我们在包含RSS源的数据库上构建API，然后抓取源和项目将需要以下内容：

+-----------+--------------------+
|   REST    |        SQL         |
+-----------+--------------------+
| GET /feed | SELECT * FROM feed |
+-----------+--------------------+

接下来就是其中之一

+-------------------------+-----------------------------------------------+
|          REST           |                      SQL                      |
+-------------------------+-----------------------------------------------+
| GET /feed/1/item        | SELECT * FROM item WHERE feed_id = 1          |
| GET /item?feed_id=1,2,3 | SELECT * FROM item WHERE feed_id IN (1, 2, 3) |
+-------------------------+-----------------------------------------------+

如果你想做的话，如果你想一次一个或分别聚合。

---

我想知道的是，如果使用较少的模块化并使用JOIN和聚合来接近它是否有任何好处，例如，如果您事先知道需要聚合，那么您将使用

+--------------+---------------------------------+
| REST         | SQL                             |
+--------------+---------------------------------+
| GET /feedagg | SELECT                          |
|              |   f.*,                          |
|              |   json_agg(i.*) as items        |
|              | FROM feed f                     |
|              | JOIN item i USING (feed_url)    |
|              | GROUP BY f.feed_url             |
|              | ORDER BY f.title ASC            |
+--------------+---------------------------------+

这是一个更多的SQL，但另一方面，它只有一个SQL查询和只有一个API请求。

---

我知道这两种方法可以共存，因为我把它们放在不同的路线上，但我不清楚的是第二种方法实际上是否优于第一种方法。 它似乎更好，因为请求/查询数量较少，但我找不到详细说明这方面资源的资源。

关于第一种模块化方法的例子非常多，但相比之下，人们使用JOIN +聚合的在线示例严重缺乏。 我没有经验，而且我知道很多因素，包括我可能没想到的因素，都在起作用。

可能性能差异可以忽略不计，但无论如何，我想得到两种方法的pro / con细分。 有人可以为我澄清一下吗？

Answer 1

通常， 1 API查询将快于2，因为准备2个单独查询的开销很大，但是否可以利用这些优势取决于API的使用方式。

如果您的用户不打算通过GET /feedagg方法使用API​​，那么性能就没有明显的好处。

您所说的模块化是REST的关键原则，它将您的API划分为逻辑Resources 。 实际上，坚持使用模块化方法，除非你的API总是以第二种方式使用，在这种情况下，这样做可以实现它提供的性能优势。

这是一个关于实用RESTful API开发的重要资源： http ： //www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#ssl

Answer 2

哪一个更好取决于您的客户需求和您的应用实施。 理想情况下，您应该使用第一种方法，因为它更灵活，更易于标准化，并通过缓存解决任何性能问题。 第二种方法可能会为您保存请求，但根据您的API可能会强制您为所有资源实施此类聚合收集资源。

我在某些情况下使用的另一种方法是我称之为“缩放协议”。 您允许资源在embedded属性中嵌入子资源， _zoom查询参数告诉API要嵌入多少级别。 例如，假设您使用的是JSON表示， GET /feed/1?_zoom=1将返回Feed的表示形式，并将所有项目和任何其他子资源作为数组embedded到embedded属性中。 使用GET /feed/1?_zoom=2它返回项目的所有项目和子项，依此类推。

更复杂的方法是提供标准查询语法，客户端可以使用它来查询他们想要的资源，在URL查询字符串中复制一些简单的SQL查询。 这在某些情况下非常有用，但在其他情况下则是一种负担。 RQL语言是一种可用于实现类似内容的查询语言。