最近在做交易云服务接口，对接各个业务方的时候，存在一些争议。业务方认为，一些营销、物流相关的信息应当由交易来封装返回，而交易则认为这些信息并不是自己所关心的，应当由业务方根据自己的需要去对应的基础服务接口获取和定制。 公说公有理婆说婆有理，我个人的观点如下：
首要是关注点。谁去调用谁，只是个小的技术细节。灵活组合基础服务接口上玩出有潜力的业务，才是真正要关心的事情啊！
对于业务方来说，基础服务接口提供的是最基本的土壤和水的作用，而不是酸性或碱性的施了某种肥料的土壤，是高稳定、高吞吐量、高流畅的、极低bug率的正交的聚焦于自身领域的服务，而不是一时便利的一条龙服务。应该赋予业务方强大的可组合的、依赖干净的服务。
想想，如果在 find 里加点 grep 的功能，或者在 grep 里加点 find 的功能，固然在初始时能带来方便，可是发展到复杂任务的时候，程序会变慢、不稳定、bug率上升、依赖关系错综复杂，你期望勤恳耕耘的时候脚底下不时震一震么？
上圣，民不知其有；上明，民感其恩德。基础服务接口应当尽量做到用过就像不存在一样，而不是时不时来找升级。
掺杂了其他信息的杂烩性接口有什么利处和弊端呢？
利处明显，方便了业务方的使用，让业务方省了一时的心。
弊端也很明显。假设业务方X依赖接口A。
(1) 接口A原本是30ms 返回，调用另一个 30ms 的接口B获取额外信息，那么其吞吐量就会降低一半；如果 B 超时，那么还会导致 A 的响应和吞吐量进一步降低，甚至服务不稳定；
(2) 当B因为某个业务方X需要升级时，A也要同步升级以供X使用，而依赖A的其他业务方并不需要这个升级，却受到了牵连影响；假设 A 因为某种原因不能及时升级，业务方X的产品进度就会受到影响；
(3) 不必要的测试与沟通成本。若 A 依赖 B，那么联调时，当 B 出现问题时，无论是否为 A 的问题， A 都需要去找 B 去修复，存在比较大的传递沟通成本； 若 X 分别依赖 A 与 B ，那么 A 提供足够稳定高效的服务接口。 B 有问题，让 X 与 B 单独沟通去， A 可专注于解决自身领域的问题。测试亦存在传递测试成本。
(4) 不必要的依赖。 X 依赖 A ， A 依赖 B， 而原本 A 与 B 是平行的关系，这样在底层又增加了不必要的服务依赖关系，久而久之，就形成错综复杂的依赖网，走回原来的老路了。
(5) 小而美的接口足够稳定足够快，快到BUG还没反应过来就已经返回结果啦； 而掺杂了其他信息的接口则给BUG留下了反应过来的时间。
Do less, Done more.
如果有5个高稳定性的能以30ms返回的小而美的接口，以及2个融合了其它信息的可能不稳定的杂烩接口，我宁愿选择第一种。调用接口只是几行代码的事情，灵活而强大才是长远之选。贪图一时便利，正是埋下祸患之时。
干净、正交的服务，就像设计优良的拼板，有雄心的业务方理解每个拼板的能力和潜力，想办法拼出宏大的版图，而基础服务接口提供的，就是让每一块拼板美观、流畅、牢固、耐用、完全可放心使用。
小而美，组合才是力量之源。