这样的api设计合适么

[tt0411]

最近开始帮人做一个安卓app，服务器的api是另一个人写的。开始看api时，发现一个问题，就是比如请求一个items列表，每个item中有一个关联的user，但是从返回的json来看，关于这个user只有一个userid。我就问web端（像个SPA应用）的同事要显示user的其他属性咋办，他的回答竟然是根据每个userid请求另一个有完整信息的api。当时我就震惊了，web版看样子应该做了至少一个月了，这个问题就是一直这么解决的？回答说，api那边说先这么用。当然这些不是提问的重点。

我和负责api 的人（兼职的，其实我也算兼职）交流了，他勉强认同了这么做不合适，而他给出的解决方案是提供另一个api接口，这个接口接受现有的几个api的地址和参数的组合合并（就是发送一个包含api地址和参数的数组），发送为一个api请求，从而减少请求数。他的理由是这样的合并方式比较灵活，api这边需要维护的接口不会太多。我没怎么写过服务器端的api，却也用过一些，总感觉这样做不合适，而又说不清楚，同时又是人微言轻。我想问下有人做过类似的设计么？这种设计（api组合）合适么？

[tt0411]

@lightory
@tshwangq

batch request是个不错的概念，学习了。但是感觉会增加客户端编程的复杂性。同时我更认同 @dorentus 的观点，api应该“黑盒”，不能暴露内部细节。

[lightory]

@tt0411 @dorentus

我觉得还是要看 API 是公开给外部开发者，还是仅供内部开发者使用。我猜 @tt0411 的情况是后者。

那么：

1. 内部使用的 API，往往后续需求变动的可能性比较大。如果对于每个需求都新增 API（或在现有 API 增加字段），维护成本会异常大，将每个 API 拆分到足够小的粒度是比较好的做法。这么做也有其它一些额外的好处，譬如简化缓存的实现。

2. 内部开发者应当对数据模型及关系有清晰的认识，黑盒不黑盒不是太大的问题。

另外，关于客户端的复杂度。如果服务端做 batch request，客户端应该也有相应的封装。

[GTim]

参考新浪微博的use返回方式，不错的