• #2楼 @godsme 是否可以这么理解:我们只提供刚好满足用户需求的API,如果部分用户需要下层的API的时候,就在他们提出这种需求时候再去做“抽取”和提供。

    “抽取”的意思就是:往往上层的API的实现逻辑包含了下层API(但是这个时候没有需求,所以下层API没有独立封装),当用户提出下层API时候,则从上层的API中抽取和封装成下层API。

  • 我的想法是这个问题可以有2个角度:
    1. 从“用户”角度出发,让用只提供必须的信息,其他的都应该在API内部实现——说白了,就是让API好用、易用。
    2. 从“API供者“角度出发,尽量让每个业务步骤做成”原子化“——需要某个业务能力时候,使用者自行”组装“。这样不好用,但是对“API供者“比较稳定。

    我之前的经验1和2的方式都有,但是2的数量比较多。
    比如我们平台组为了”业务开放性“提供的SDK,不确定第三方集成时候对中间过程的状态的需求,因此往往是采用2这种模式。

    我们在1和2之间是否应该有平衡(我的看法是应该全部按照1实现)?
    这个平衡怎么来做——比如举个具体例子:发送一条IM消息。那么是否要分成几个步骤单(上传富媒体/发送消息/发送状态通知)独提供API?