有关 Restful API 的疑问

[bdbai]

比如说有个获取帖子的 API ，应不应该把发布者的用户名、头像地址一起传回？还是只留个用户 ID 即可？

[msg7086]

@bdbai 是啊。这就是典型的 N+1 问题优化。 1 个请求+N 个子请求，优化成 1+1 一共 2 个请求。

[atom]

孤立看问题的撕逼钓鱼贴 :)
response 的 size 不是过大的时候，一次请求“就近”返回信息，减少连接数，效果是很客观的。
没做过 APP ，单纯从桌面浏览器来看，连接数过多页面加载的效果非常差，而且 js 的调度，一般认为是个单线程的东西。

[loading]

@msg7086 其实你看懂了，我为了说明楼主这个只传 id 的缺陷，就按没合并的情况下说的。

楼主这个就是先给 id 然后又至少根据 id 查一次的情况，这个明显就应该合并！

[bdbai]

@msg7086 @loading 好的好的 合并合并:)
@atom 本无意钓鱼...

[msg7086]

@loading
@bdbai
我反正觉得应该分开。

[loading]

@msg7086 我发出以上内容的出发点是:楼主说的 id ，我理解是 id 号~因为我看到楼主还说了用户名这个东西，所以我就单纯地理解为 id 是个数字，也就是我们说的 uid

[loading]

@loading 因为我觉得应该不会给用户一个数字，必须要把它变成用户名，如果只是这个问题，我的观点就是合并，在 sql 时就是一个 join 的问题，毕竟如果不返回，马上就必须来个请求找用户名了。

这是我回答这个问题的过程。


也许跑偏了太多~

[msg7086]

@loading 所以我觉得应该分开，让 API 做到单一职责。

以前用 PHP 的时候，习惯于大量用 SQL 语句做 JOIN ，因为这样方便，一句话返回所有我要的数据就行了。
这种情况下自然就产生出你说的这种输出方式，用 JOIN 把用户数据一起加载进帖子数据里。

现在用 RoR ， ActiveRecord 倾向于分开查询，就是第一次先查帖子数据，然后用拿到的用户 ID 去做第二次查询。好处是查询更容易被缓存，以及表结构更容易做性能优化。（毕竟索引只要建在主键 /外键上就好了）这样就自然而然出现了两次查询的做法，即：

get_json (:posts )
.then {
- display_posts
- find_user_ids
- return get_json (:users, user_ids )
}.then {
- replace_user_info_by_id
}

[luago]

建议回传，客户端如果已经缓存了头像，你的传输成本只是增加了用户名和头像地址的字符串长度而已。

[railgun]

加个开关，让客户端自己判断就好了

[bdbai]

@luago 积少成多 另外客户端还能缓存用户信息呢
@msg7086 隐约感觉外部可以全都传 系统里面还得抽象

[boywang004]

个人倾向于接口设计成原子性的，减少接口设计和视图耦合后造成的接口数量爆炸或者维护成本陡增。至于减少请求次数或者减少 RTT 开销，可以交给底层做。比如吧，直接上 http/2 。
至于楼主问的索引和实体数据要不要一起返回，如果架构设计允许，分开返回可以设计成客户端本地缓存部分数据，减少下行量（增加的一次请求开销在 http/2 或者 spdy3.1 下不会太多）。但是设计不好很容易增加复杂度和 bug 率或者响应时间陡增之类的，所以没啥时间简单做就一起返回啦。

[zhangv]

RESTful 是 API 的设计约定，说的简单点就是你设计一个 function 的参数和返回值是什么样子的。 --- 这些首先取决于你的需求（也就是使用这个 function 的人），而不应该是首先考虑是否应该减少内存使用。