主流Web架构相互比较

做WEB好几年了，各种语言和技术都稍有涉猎。今天心血来潮，突然想总结⼀下。其实不论什么技术，什么需求，通常WEB开发就是通过WEB前端管理⼀个或⼤或⼩或独⽴或分布式的关系型数据库，很多东西都是相通的。这⾥说的WEB架构，是指WEB应⽤开发中每种技术独有的资源组织形式（包括⽂件，数据库，HTTP请求处理等。注意并⾮OO的开发⽅式才有架构⼀说），也许说开发⽅式更容易让⼈理解⼀些。

REST架构风格是全新的针对Web应用的开发风格，是当今世界最成功的互联网超媒体分布式系统架构，它使得人们真正理解了Http协议本来面貌。随着 REST架构成为主流技术，一种全新的互联网网络应用开发的思维方式开始流行。

REST是什么

REST是英文Representational State Transfer的缩写，中文翻译为“表述性状态转移”，他是由Roy Thomas Fielding博士在他的论文 《Architectural Styles and the Design of Network-based Software Architectures》中提出的一个术语。REST本身只是为分布式超媒体系统设计的一种架构风格，而不是标准。

基于Web的架构，实际上就是各种规范的集合，这些规范共同组成了Web架构。比如Http协议，比如客户端服务器模式，这些都是规范。每当我们在原有规 范的基础上增加新的规范，就会形成新的架构。而REST正是这样一种架构，他结合了一系列的规范，而形成了一种新的基于Web的架构风格。

传统的Web应用大都是B/S架构，它包括了如下一些规范 。

客户－服务器

这种规范的提出，改善了用户接口跨多个平台的可移植性，并且通过简化服务器组件，改善了系统的可伸缩性。最为关键的是通过分离用户接口和数据存储这两个关注点，使得不同用户终端享受相同数据成为了可能。

无状态性

无状态性是在客户－服务器约束的基础上添加的又一层规范。他要求通信必须在本质上是无状态的，即从客户到服务器的每个request都必须包含理解该 request所必须的所有信息。这个规范改善了系统的可见性（无状态性使得客户端和服务器端不必保存对方的详细信息，服务器只需要处理当前 request，而不必了解所有的request历史），可靠性（无状态性减少了服务器从局部错误中恢复的任务量），可伸缩性（无状态性使得服务器端可以 很容易的释放资源，因为服务器端不必在多个request中保存状态）。同时，这种规范的缺点也是显而易见得，由于不能将状态数据保存在服务器上的共享上 下文中，因此增加了在一系列request中发送重复数据的开销,严重的降低了效率。

缓存

为 了改善无状态性带来的网络的低效性，我们填加了缓存约束。缓存约束允许隐式或显式地标记一个response中的数据，这样就赋予了客户端缓存 response数据的功能，这样就可以为以后的request共用缓存的数据，部分或全部的消除一部分交互，增加了网络的效率。但是用于客户端缓存了信 息，也就同时增加了客户端与服务器数据不一致的可能，从而降低了可靠性。

B/S架构的优点是其部署非常方便，但在用户体验方面却不是很理想。为了改善这种情况，我们引入了REST。

REST在原有的架构上增加了三个新规范：统一接口，分层系统和按需代码。

WEB程序的架构基本上可以分成以下三类：

(⼀) 基于“WEB页⾯/⽂件”，例如CGI和PHP/ASP程序。程序的⽂件分别存储在不同的⽬录⾥，与URL相对应。当HTTP请求提交⾄服务器时，URL直接指向某个⽂件，然后由该⽂件来处理请求，并返回响应结果。

可以想像，我们在站点根⽬录的news⽬录下放置⼀个readnews.php文件。

这种开发⽅式最⾃然，最易理解，也是PHP最常⽤的⽅式。要注意产⽣的URL对搜索引擎不友好，不过你可以⽤服务器提供的URL重写⽅案来处理，例如Apache的mod_rewrite。

(⼆) 基于“动作”(Action)。这是MVC架构的WEB程序所采⽤的最常见的⽅式。⽬前主流的WEB框架像Struts、Webwork(Java)，Ruby on Rails(Ruby),Zend Framework(PHP)等都采⽤这种设计。URL映射到控制器(controller)和控制器中的动作(action)，由action来处理请求并输出响应结果。这种设计和上⾯的基于⽂件的⽅式⼀样，都是请求/响应驱动的⽅案，离不开HTTP。

可以想像在实际代码中，我们会有⼀个控制器newsController，其中有⼀个readAction。不同框架可能默认实现⽅式稍有不同，有的是⼀个Controller⼀个⽂件，其中有多个Action，有的是每个Action⼀个⽂件。当然这些你都可以⾃⼰控制，题外话。

这种⽅式的URL通常都很漂亮，对搜索引擎友好，因为很多框架都⾃带有URL重写功能。可以⾃由规定URL中controller、action及参数出现的位置。

另外，还有更直接的基于URL的设计⽅案，那就是REST。通过⼈为规定URL的构成形式（⽐如Action限制成只有⼏种）来促进⽹站之间的互相访问，降低开发的复杂性，提⾼系统的可伸缩性。REST对于Web Services来说是⼀个创新。

虽然本⽂讨论的是单个项⽬所采⽤的架构，⽽REST是为了解决⽹站之间的通讯问题，但REST的出现，会对单个项⽬的架构造成影响（很显然你在开发时就要构造规范的URL）。将来混⽤REST和MVC应该也是⼀种趋势。RoR提供很好的REST⽀持，Zend Framework也提供了Zend_Rest来⽀持REST，包括Server和Client。

(三) 基于“组件”（Component ，GUI设计也常称控件）、事件驱动的架构，最常见的是微软的.NET。基本思想是把程序分成很多组件，每个组件都可以触发事件，调⽤特定的事件处理器来处理（⽐如在⼀个HTML按钮上设置onClick事件链接到⼀个PHP函数）。这种设计远离HTTP，HTTP请求完全抽象，映射到⼀个事件。

事实上这种设计原本最常应⽤于传统桌⾯GUI程序的开发，例如Delphi，Java Swing等。所有表现层的组件⽐如窗⼝，或者HTML表单都可以由IDE来提供，我们只需要在IDE⾥点击或拖动⿏标就能够⾃动添加⼀个组件，并且添加⼀个相应的事件处理器。

这种开发⽅式有⼏个优点：

复⽤性 -代码⾼度可重⽤。

易于使⽤ -通常只需要配置控件的属性，编写相关的事件处理函数。

我个⼈也挺喜欢这种⽅式，PEAR就提供了相当强⼤的HTML_QuickForm，用于在页面添加表单元素及其事件处理函数，还可以与Smarty等模板引擎相结合。这对于项⽬开发来说是⼀个补充性的功能，在项⽬中的某些部份使⽤QuickForm，有时可以⼤⼤加快开发。

REST、SOAP、XML-RPC是常用的Web接口标准。其中REST（Representational State Transfer）是一种轻量级的Web Service架构风格，其实现和操作比SOAP和XML-RPC更为简洁，可以完全通过HTTP协议实现，还可以利用缓存来提高响应速度，在性能、效率和易用性上都优于SOAP协议。

REST风格的接口可以使用各种语言（如Java、PHP和Javascript）进行调用，也可以直接使用HTTP客户端进行调用，这种简便性让用户能够与之直接交互，使用Web浏览器构建一个GET URL并读取返回的内容，方便调试和测试。

REST架构让人们易于理解网络协议HTTP本来面貌，对资源的操作包括获取、创建、修改和删除，正好对应HTTP协议提供的GET、POST、PUT和DELETE方法，因此REST把HTTP对一个URL资源的操作限制在GET、POST、PUT和DELETE这四个之内。

REST架构风格的核心特征就是强调组件之间有一个统一的接口，其目的是为了降低开发的复杂性，提高系统的可伸缩性，保证系统提供的服务都是解耦的，从而改善了系统的交互性和可重用性。

既然REST这 么好用，那么是不是所有的Web应用都能采取此种架构呢？答案是否定的。我们知道，直到现在为止，MVC(Model-View-Controller) 模式依然是Web开发最普遍的模式，绝大多数的公司和开发人员都采取此种架构来开发Web应用，并且其思维方式也停留于此。MVC模式由数据，视图和控制 器构成，通过事件(Event)触发Controller来改变Model和View。加上Webwork,Struts等开源框架的加入，MVC开发模 式已经相当成熟，其思想根本就是基于Action来驱动。从开发人员角度上来说，贸然接受一个新的架构会带来风险，其中的不确定因素太多。并且REST新 的思维方式是把所有用户需求抽象为资源，这在实际开发中是比较难做到的，因为并不是所有的用户需求都能被抽象为资源，这样也就是说不是整个系统的结构都能 通过REST的来表现。所以在开发中，我们需要根据以上2点来在REST和MVC中做出选择。我们认为比较好的办法是混用REST和MVC，因为这适合绝 大多数的Web应用开发，开发人员只需要对比较容易能够抽象为资源的用户需求采取REST的开发模式，而对其它需求采取MVC开发即可。这里需要提到的就 是ROR(Ruby on Rails)框架，这是一个基于Ruby语言的越来越流行的Web开发框架，它极大的提高了Web开发的速度。更为重要的是，ROR(从1.2版本起)框 架是第一个引入REST做为核心思想的Web开发框架，它提供了对REST最好的支持，也是当今最成功的应用REST的Web开发框架。实际上，ROR的 REST实现就是REST和MVC混用，开发人员采用ROR框架，可以更快更好的构建Web应用。

对开发人员来说，REST不仅仅在Web开发上贡献了自己的力量，同时也让我们学到了如何把软件工程原则系统地应用于对一个真实软件的设计和评估上。