API优先架构或者胖瘦服务器之争
2013-10-16 02:20 |来自: CSDN|
查看: 3939|
评论: 0
自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)并不能直接给业务带来价值,却可以降低应用未来修改时的成本,然而这种程度的说服力显然难以服众。 |
免责声明:
除非特别声明,文章均为投稿或网络转载,仅代表作者观点,与大数据中国网无关。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。如果本文内容有侵犯你的权益,请发送信息至ab12-120@163.com,我们会及时删除
最新评论
最新新闻
最新新闻