传统网站开发,习惯于站在当前业务而不是数据角度。按照其思维惯性,对于API,服务器应把多个接口的业务逻辑合并成一个接口,客户端只需发送一次http请求就可以搞定所有数据。合并成一个接口,会产生两个问题:第一,任意一个小的业务变动将导致整个接口的剧烈变化。第二,API没办法复用,函数、类很难复用。从数据角度出发,API保持一定程度的独立性,有利于复用。但如果仅仅“所见即所得”,API通用性将变得很差。
多个接口也不是只有好处。过多的http连接,会造成服务器的压力。
接口粒度的把握,不是一个看起来那么容易的问题。这属于经验性问题,通常由架构师根据具体业务来决定。粒度过粗,复用性不好,不够灵活;粒度过细,客户端调用不方便,发送太多的http请求,而http请求很可能是异步的,这又涉及到数据合并。因此,接口设计是门复杂的学问,有很多经验性问题,涉及到分层、架构、性能等。
如同Model可以分为Model、Service、Logic三层,API也需要架构,做好分层。在最底层,提供粒度非常小的、灵活性高的API接口;往上的层,粒度逐步变粗。业务足够复杂时,本身API可以视作基础数据API。如果某一业务所需要的接口调用数据太多,应在基础数据API层上建立业务层,在业务层的内部调用基础数据API层的相关接口,把其封装为统一的、适合于当前访问的业务,依次返回到客户端。事实上,很多大型项目都做有基础数据层、服务层等分层。
领取专属 10元无门槛券
私享最新 技术干货