设计 RESTful API 时，如果前端同一页面需要请求几条不相关的数据时，是分开逐条请求么？有没有打包请求多组数据的设计？

[newtype0092]

不相关的数据是指：假如我想在某个页面显示物品列表时，同时底部滚动展示一些 tips，可能还需要一些展示相关的配置数据。
这些数据如果按 RESTful 设计的话感觉是不该放在一个 API 里的，但如果是数据种类很多但每种数据量较少时，肯定是一条请求获取的效率比较高吧。

[xiaoxinxiaobai]

看你怎么定义资源吧，可以灵活掌握

[iappled]

Graph API

[auroraccc]

graphql 了解下

[whuhacker]

HTTP2 链路复用已经解决了效率问题

[changrui0608]

服务器端可以这样返回:
｛"resource": 资源本体, "tips": tips 本体, "config": 配置数据｝，
或者把 tips 和 config 都放进一个叫 metadata 的字段内，这些都还算是 restful 的常用做法。

[wizardforcel]

测一下哪个更快

rest 的设计上可以创建新的只读资源 xxxPageData，包含原有资源 items, tips, ... 作为其属性

[artikle]

Graphql+1，不过效率要权衡，正常是偏低的

[zhandi]

网关吧

[stillsilly]

RESTful 不适合完全照搬它那些原则写业务…… 粒度太粗……

[wish198]

RESTful 这些年被翻出来感觉有点被炒作的感觉，当时看了一圈 BAT 的实际使用的 API 就能感觉出来，RESTful 以请求动作来区分 API 功能在实际使用就是爽流氓

[newtype0092]

@stillsilly @wish198
最近才开始做后端，看了下 RESTful 相关的东西，感觉设计的非常清晰，看起来很优雅，教程上的例子都特别合适，但对一下自己的业务发现完全照这么设计每一页都得发好多请求才行。。。

[newtype0092]

@auroraccc @artikle 还是新手，感觉这个东西成本略大，正在跑的系统不太敢这么折腾。。。

[wish198]

@newtype0092 你的问题其实分开合并都可以，但是要考虑实际情况。
如果拆成多条网络请求可能会减少设计上的耦合，但是可能会占用带宽。 算下请求的频率和使用率。反正还是看业务，不要死守着什么 RESTful

[banks0913]

按照 restful 的接口设计原则，除了对简单 Entry 的 CRUD, 其他杂七杂八的业务很难满足

[liuzelei]

这就需要你的架构师好好考量你们的设计。
一般实践中，api 的设计都不是跟着客户端走的，而是跟着业务走的，你业务抽象的好，你的 api 就能规划的很好，自然就会 restful。
但是很不幸，很多的系统 api 写的跟 shit 一样，这里面包括很多 bat 的 api，都跟 shit 一样。

[param]

Graph API
另外如果有类似需求的话，试一下自己封装一下把多个请求合并为一个

[stillsilly]

增删改查这 4 个动作，能完全覆盖、精准地描述你们的花式的业务需求吗？
如果不能，那就不要完全照搬那些原则…… 只用方便使用的那部分

[newtype0092]

@param 现在就是封装过的，只是感觉没法做到那么符合 RESTful 标准，因为没办法一个 API 只做一件事。。。

[newtype0092]

感觉纯的业务请求都还好，主要是 GET 数据的时候，为了优化体验总是会根据前端页面的展示需求去封装数据，这种时候就会混合一些可能不相关的东西打包返回，也就不 RESTful 了。
网上看了一些资料都说要尽量 RESTful，所以以为大家是不是有什么方法专门应对这种问题，不过看大家的回复好像那些文章都有点极端吹了。。。

[IvanLi127]

实在多就套层 api 网关整合下吧。api 改花了也不好。。。