从REST API构造和排序一对多关系客户端



我有点难以理解如何从REST API中提取一对多关系,然后在客户端使用Javascript将其全部显示在页面上。

举个例子,假设我有postscategories。我希望我的页面显示一个类别列表,下面有每个帖子的标题和描述

Category 1
- Post 1
- Post 2
- Post 3
Category 2
- Post 4
- Post 5

我试图弄清楚如何构建我的API,然后组织数据。最好的方法是构建API,以便我们达到:

/categories/ID/posts

要获得每个类别的帖子列表吗?或者只是在posts端点本身添加一个类别过滤器,如:

/posts?category=ID

然后在客户端,我会向/categories/发出请求以获得类别列表,并为每个类别发出一个请求以获得每个类别的帖子列表。

或者,在/posts/(甚至/all/,我在一些地方看到过)有一个端点,它已经通过将数据分组来按类别组织数据,这会更好吗。我知道这不是RESTful,但这是最好的方法吗?在客户端,我会遍历列表并相应地分组。

我认为第一个选择是要走的路,我唯一担心的是这可能会变成很多请求。如果有十几个或更多的类别,我必须为每个类别提出一个单独的请求,加上最初的一个,至少13个。这似乎很浪费。优点是,一旦我以这种方式获得所有数据,就可以在客户端将其分解并组织成子视图。所以我想知道是否还有另一种我没有看到的最佳实践方法来处理这个问题。

每种方法都有优缺点。

第一种方法:对每个类别的提出请求

这些请求很多,但它可以用来逐个调用和显示类别:让我们假设一个类别及其文章列表的可视化占据了整个用户屏幕:您可以首先对第一个类别发出请求并显示它(这样用户就可以在不必处理所有数据的情况下查看一些内容),然后对第二个类别发出API调用,以此类推

如果因为只发出一个请求而不传递大量数据,那么第二种方法会更好。

概括一下:
每个类别一个请求

  • 许多请求
  • 轻量级请求
  • 无需等待所有数据即可显示第一个类别

一个完整的请求

  • 只有一个请求
  • 服务器处理的请求可能很重
  • 客户端将所有类别显示在一起

哪个更好在很大程度上取决于的具体情况

最新更新