REST+RIA方案
一直很想体会一下使用REST+RIA这种组合开发Web应用效果究竟如何,乘着这几天有空简单试验了一把
在后续过程中,方案二的优点就体现出来了:由于购物车是在客户端处理的,结账的表单也嵌入在SWF中,因此方案二可以在绝大部分时间不必与服务器通信,只在最后提交表单的时候需要再次请求服务器。方案一虽然每次请求的数据量都不大,但是请求次数相当频繁,对于服务器来说负担仍然相当沉重,而且请求次数越多,由于网络问题等原因出错的可能性也越大。
仔细观察表中的数据也能看出一些有意思的结论。请看方案一中的步骤2和步骤3:步骤3清空购物车使用的传统的Web方法,即向服务器发出请求,然后重新载入整个页面;步骤2添加一件货品,使用的是Ajax方法。两个步骤其实数据量差不多大小,步骤2还要多出一个product_id参数,但是无论从请求数量(1:3)还是数据量大小(1851:9927)都表明Ajax比传统的全页面刷新方法要优越得多。不过在这个方面,RIA走得更远:完全不需要向服务器请求,客户端本身就可以完成相当一部分工作。
结论
REST+RIA是一种新兴的Web应用结构,这种结构具有如下的优点:
1、将表现层与后台彻底分离
传统的Web表现层技术总是依赖于特定的服务器编程语言的。比如你用JSP编写页面,就意味着服务器后台必须使用Java,如果后来决定改用ROR,那么除了用rhtml重写表现层以外大概没有什么更好的办法。而使用RESTful风格的接口意味着服务器只需要提供资源,不论后台使用Java,Ruby或.Net来实现,对表现层都完全没有影响,哪怕把后台整个换掉也不需要重写表现层,这也意味着表现层是完全可重用的。考虑到真实的项目中对表现层的修改往往是最麻烦且工作量极大的部分,这项分离意义重大。
要将表现层与后台分离,其实也有其他的一些技术方案可选。以前出现过的两种比较常见的办法:(1)服务器提供XML数据,然后用XSLT转换为HTML或其他格式;(2)服务器提供Web Service接口,用支持WS的客户端访问。不过这两种方法可能也存在一定的问题,最后并没有真正流行开来。Web Service更多的用在异构系统整合而不是系统内部通信上。
2、方便程序员和美工协同开发
在页面中嵌入代码是好是坏?问题不在于代码本身,而在于这样一来美工和程序员的工作难以协调,任何一方做出修改,都必须复核自己的修改是否破坏了对方的工作。RESTful风格的接口只提供资源数据,不暴露服务器上的任何实现细节,这对美工和程序员来说绝对是个好消息:只需要约定服务器提供数据的格式,美工就可以完全按照自己的节奏去设计和测试页面,程序员也可以专心实现后台逻辑,彼此都不需要担心破坏对方的工作,可以实现完全的并行开发,这是以往任何Web开发技术都没能做到的。
3、有利于采用快速原型的开发方式
在上面已经提到过,在这种方式下,美工和程序员可以完全并行工作。即使在还没有实现任何后台逻辑之前,只要先写一个符合格式的Xml占位文件,表现层就可以开始设计,不论后台开发速度快慢,表现层都可以尽快提供一个可以工作的原型,对于尽早审核需求和获得用户反馈都是非常有利的。
4、合理分配负载,减轻服务器压力
大多数Web应用在负载的分配问题上其实是非常不合理的:服务器承担着成千上万的用户请求,每时每刻都在忙碌之中,而客户端机器在这个时间里只是傻傻的等待响应,根本无事可做。从前面的测试结果可以看到,RIA的方案需要一次性下载较大的数据,但在这之后客户端可以承担相当一部分工作,避免频繁请求服务器,不仅在资源分配上更加合理,也能够让服务器同时承载更多的用户。
- 本文关键词:

