Web 的一个页面的 API 请求数要如何权衡

[Philippa]

如题,没有任何相关互联网的 web 经验,现在想到 3 种方案:

1. 创建一个 roadmap 的 api,进入该页面前首先请求这个 api,然后根据返回的 api 来请求页面的其他链接.
2. 直接写死固定几个 api 固定请求,然后继续用 roadmap 来寻找下一个需要请求的 api.
3. 直接固定写死全部的 api,直接请求.

在数量,体验等方面应该如何取得平衡比较好?我个人比较偏好 1 或 2 的,感觉 1 风险有点大,可能一片空白但逻辑上符合很符合直觉,灵活性也强.2 貌似更加常见,打算采用.3 觉得不靠谱.

不知道有没有人采用 roadmap 这种方式,会不会很慢?假如用 roadmap,采用多少层比较好?就比如 api1->api2->api3,api3 需要从 api1 先获取 api2,再从 api2 获取 api3.

谢谢!

[Philippa]

目前想法是限制在几个最多 10 个之内,然后在逻辑上区分会分成几个,然后写死几个,分太多前端可能意见会很大 = =. 最迷惑是 roadmap 的层数问题和是否使用, 不知道有经验人士是否体验过实际体验怎么样?谢谢!