接口粒度：API复用性与服务器压力之间的平衡

传统网站开发，习惯于站在当前业务而不是数据角度。按照其思维惯性，对于API，服务器应把多个接口的业务逻辑合并成一个接口，客户端只需发送一次http请求就可以搞定所有数据。合并成一个接口，会产生两个问题：第一，任意一个小的业务变动将导致整个接口的剧烈变化。第二，API没办法复用，函数、类很难复用。从数据角度出发，API保持一定程度的独立性，有利于复用。但如果仅仅“所见即所得”，API通用性将变得很差。

多个接口也不是只有好处。过多的http连接，会造成服务器的压力。

接口粒度的把握，不是一个看起来那么容易的问题。这属于经验性问题，通常由架构师根据具体业务来决定。粒度过粗，复用性不好，不够灵活；粒度过细，客户端调用不方便，发送太多的http请求，而http请求很可能是异步的，这又涉及到数据合并。因此，接口设计是门复杂的学问，有很多经验性问题，涉及到分层、架构、性能等。

如同Model可以分为Model、Service、Logic三层，API也需要架构，做好分层。在最底层，提供粒度非常小的、灵活性高的API接口；往上的层，粒度逐步变粗。业务足够复杂时，本身API可以视作基础数据API。如果某一业务所需要的接口调用数据太多，应在基础数据API层上建立业务层，在业务层的内部调用基础数据API层的相关接口，把其封装为统一的、适合于当前访问的业务，依次返回到客户端。事实上，很多大型项目都做有基础数据层、服务层等分层。