By 高焕堂 2013/06/01
服务端(Server)框架API的设计策略
一、从古典API到新潮API
如果你是服务端业者，如何规划强势的API呢? 服务端业者天生就具有成为「强龙」的优势条件。然而，由于API的古典迷思，让天生强龙陷入「虎落平阳被犬欺」的困境。原来的强龙变成「小弟」了。在Client/Server架构下，API呈现于Client与Server之间。这API也成为分工开发的界线。通称为「古典API，传统分工」模式。
图1、古典的API，传统的分工
在这种架构里，是服务端提供服务给Client端，犹如Service_imp种南瓜给Client吃，显然地，服务端受制于Client端，所以服务端无法对Client端产生制约性力量。此外，API通常是开发团队之间分工的界线。[歡迎光臨 高煥堂 網頁： http://www.cnblogs.com/myEIT/ ]
那么，在上图里，由于服务端的func()函数名称被Client端抓住了，它的稳定性、自主性和自由度受限于Client需求的变动。所以，服务端开发团队，常常成为救火队而疲于奔命。即使，加上一层Adapter(或称Shell)也是无济于事，如下图：
图2、即使加一层Shell，问题还是一样
此时，服务端可以巧妙地应用父、子类别之间的API，做为分工的界线。这个新潮的API可以让服务端拥有制约力量，且不必疲于奔命。如下图：
图3、创造新API，取得境内主导权
以上，在境内(服务端)取得制约力量，藉由新API而获得主导权。进一步将势力拓展到境外，取得全面性的主导权。
图4、创造具有全面主导权的架构
或是，采取更具主导性的架构，如下图：
图5、更具主导性的架构
二、Android的范例
在Android里，Service是服务端的主要父类别，而Activity则是在Client端的主要父类别。这两个父类别相互呼应，取得手机内部的全面性主导权。如下图：
图6、Android的主导性架构
此外，在跨进程(IPC)或跨AP的环境里，Android也提供Binder父类别来主导其间的API和通讯。如下图：
图7、Android跨AP的主导性架构
从Android手机端遥看Google云层上，也是以新型API来主导全局，如下图：
图8、更具主导性的架构
当我们(或Google)再从云层往端看来，可以看到更多的端，当然包含目前最热门的Google Android电视，如下图：
图9、版图继续扩大到电视机
当我们更巧妙地运用Google Android TV，在Android TV上安装i-Jetty Web Server，更是如虎添翼，让电视机摇身一变，飞上枝头变凤凰，从「端」变成「云」，如下图：
图10、电视机从端变成云
三、结语
无论是硬件厂商或网络服务公司，大多处于服务端的角色。若依循古典API，基于传统分工，上述业者大多「被人掐着脖子走」(台湾新国众集团 简明仁 董事长的话)。现在，我们终于能理解及运用新潮API，拓展本身的主导权，抛弃脖子上的枷锁了。◆
[Go Back]
