REST关系，使用SQL联接获取模块化(多个请求)和聚合(单个请求)的利弊

Question

通常，据我所见，REST是以模块化方式实现的。例如，假设我们正在一个包含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) |
+-------------------------+-----------------------------------------------+

如果你想这样做，如果你想一次做一次，或者分别做一次。

我想知道的是，使这种模块化程度更低，并使用联接和聚合来处理它是否有什么好处，例如，如果您事先知道您需要一个聚合，那么您可以使用

+--------------+---------------------------------+
| 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请求。

我知道这两种方法可以共存，因为我把它们放在不同的路径下，但我不清楚的是，第二种方法是否真的比第一种更好。它似乎更好，因为请求/查询计数较少，但我无法找到详细说明这方面的任何资源。

关于第一种模块化方法，有大量的例子，但相比之下，人们在网上使用联接+聚合的例子却严重缺乏。我没有经验，我知道很多因素，包括我可能没有想到的因素，都在发挥作用。

这可能是性能差异是可以忽略不计的，但无论如何，我想得到一个正反两种方法的细分。有人能帮我澄清一下吗？

Answer 1

一般来说，由于准备两个单独查询的开销，1 API查询将比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将返回提要的表示，并将所有项和任何其他子资源作为数组嵌入到embedded属性中。使用GET /feed/1?_zoom=2，它返回项的所有项和子项，依此类推。

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