自2007年Apple发布了iPhone，网络应用及网站在小屏幕上的呈现机会显著的增高，从而各大网站及机构不得不对其应用进行适当的改变。然而考虑到数据体积、应用程序扩展性、新特性的发布及维护等问题，应用程序的架构也不得不按需进行改变，比如Twitter的面向服务。近日leaseweblabs上发表了一篇文章，详述了API优先架构。
以下为译文：
在API优先架构中，API用户会被视为应用程序的主要用户。这意味着API不会再作为MVC中View的替代，它将拥有最高的优先权。其中最主要的区别就是：在“API优先”中，架构会始终执行一个完整、响应式及文档化的API。而当目标指向移动（应用联连接到API）、代理商（表示层会使用API）及高整合、解耦的多产品环境中，这一点尤为重要。
MVC
MVC架构已经流行了很长一段时间，在2004年RoR发布后，MVC变得愈加炙手可热。在MVC情况下用户和员工分别使用前端和后端两个不同部分，可以大幅提高应用程序中组件的重用率。合适的使用MVC策略，可以让应用程序的很多部分都得以重用，其中包括DBAL/ORM、Business Logic、Presentation及AAA。AAA（Authentication、Authorization、Accounting）允许员工模拟用户行为，使用相同的登录界面及共享日志设备。
移动中的视图层
在2007年，Apple发布了iPhone，从那起网络应用程序（及网站）在小屏幕上的展示率迅速升高。同时MVC对小屏的兼容一直非常优秀，需要做的只是在手机或平板上开一个视图层的分支并做相关调整。这种建立独立视图层的策略被称为“mobile first”，也是最具成本效益及激进的修改途径。另一个替代方案是建立两个视图层：1个为移动设备，另一个为桌面设备。移动端的通常以“m.”的子域名开头（比如m.csdn.net），非常简单及直观的一个途径。
在MVC中加入API
“HTML5 vs Native”应用开发之争可谓是如火如荼，引用Danny Brown的话就是：
当公司在建立移动应用时会面临一个重要的抉择，Native或者是HTML5。每个方案都有自己的优势，然而错误的选择必将付出高昂的代价。
选择Native则需要建立一个完整、响应式及文档化的API，然而选择HTML5只需要重设计视图层。每种方案都有自己的优越性，只有相应的场景下才有胜负之分。所谓存在即有道理，没有哪种方案是永远的失败者：在MVC上建立API作为视图。下面就看一下，为什么许多人都选择了另一种。
首先，MVC途径需要200ms的页面加载时间。在这个途径下，服务器做3样事：数据库抽象、业务逻辑及呈现，这也是其为什么被称为fat server的原因。API并不会承担呈现工作，只执行每个请求较小的业务逻辑，也因此被命名为thin server。一个好的API会经过高度的优化，加载时间通常低于20ms。这就意味着，在执行多重调用时（高达10），一个完整页面的渲染时间不会超过300ms。
当下，如果你在使用MVC并且缺乏1个API，最容易做的事情就是添加一些View，用以输出JSON，并称之为“restful API”，唯一需要做的就是写一些文档并取悦于老板。实际上，在整个周期中，这个API完全不可用，因为其并不具备扩展性，同时还慢的可怕。
Twitter及API优先架构
在2010年，Twitter公布了他们的“API first”策略。鉴于其应用程序使用的是JavaScript，因此称之为JavaScript架构，类似于移动应用的架构。这允许他们完全重利用已有的API，这些开始时临时使用的API，在以后开发周期中却成为应用的基础。通过使用一个restful JSON API，他们的API专注于JavaScript应用程序的最佳整合。但Twitter同样使用了传统页面支撑其应用，他们曾发布：
为了不通过JavaScript支持crawler及用户，我们需要同时运行在服务器及客户端上的1个渲染系统。
使用传统网页交付方式，同时使用API优先策略，这里简单称之为“Hybrid”。下图列举了不同的途径：
结论
优化重用可以降低成本，但是只有在强壮的架构策略下才能得以实现。虽然重整代码以增加架构上的依从（compliance）并不能直接给业务带来价值，却可以降低应用未来修改时的成本，然而这种程度的说服力显然难以服众。
2013-10-15 00:00:00