以前读过Roy T Fielding的<<Architectural Styles and the Design of Network-based Software Architectures>>,其中谈到了架构的style—一组对组件及其连接的限制规则是在特定的需求和技术环境下产生的。随着时间的推移，需求和技术环境发生改变，主流架构style的思想也会随之而变的，但按照老的架构style构建的软件还存在，这不可避免的给使用者造成巨大的困惑以及冲击。比如B/S开发到富客户端开发，从富客户端(Rich Client)开发者看待B/S，就感觉其有许多问题，为什么会开发出与满足现实需求相差如此甚远的东西呢？
因此我就开始试着理解过去从C/S，静态页面，动态页面如servlet，AJAX,flash,HTML5等技术的style，来了解整个web架构发展的过程。
第一张网页是20世纪90年代诞生的，原来主要用途是发表论文等学术性文章，那这些文章的特点是改动性较少，论文发布后很少有修改的。它的进步在提出了浏览器这个跨平台的客户端，将支持的控件标准化，并采用结构描述语言—HTML来描述整个界面的布局，使用无状态的http协议来支持分布式的需求，相对于C/S的多平台客户端开发以及多平台界面元素的交互开发工作量，确实能提供开发者的效率。静态页面主要诞生于满足改动较少，显示为文本，图片等静态资源等的这种需求环境。当然技术上的跨平台，html标准的制定，http协议制定都是技术上的满足。
后来随着动态内容的增多，比如BBS等交互系统，导致网页内容改动频繁，如果采用之前静态网页的方法，估计只有用户要改动内容了，将用户的内容添入到网页中去，导致频繁发布。C/S的结构就没有这个问题，反正实时保持连接么，修改一下服务器内容再同步到其他客户端是自然支持的。广大的用户需求此时就开始推动web发展了，那能不能把C/S的这个优点吸取过来呢？如果当即拍脑门来解决这个问题，可能就会想到写一个用户在浏览器中编辑某个服务器上网页的功能，然后再提供一个服务端发布的功能。但其实分析一下，网页由数据和界面描述语言来组成，用户改动数据是合理的，界面描述语言这个用户改动量较少，且其对此的使用的专业能力不足。因此用户只需提交修改操作需要的数据，然后服务端也要做个改动，以前是数据直接写在网页里的，现在只能根据用户修改操作提交的数据临时的将数据写入网页，就会使用如tag，script等来嵌入动态内容的方式。
这种方式很OK,好多年了，大家一直信赖它。但很快的，性能又跟不上了，以前如ＣＧＩ等模式采用后台调用命令方式将用户输入参数放入命令行的参数方式去渲染网页。那每次渲染都得调用一次命令，每次调用命令得启动一个进程，进程时常创建销毁消耗资源很多。于是就有人想，其实对于一个固定的修改（一次URL请求），只是数据不同，每次的脚本内容都是不变的，那我可以把每个脚本程序搞成一个轻量级的线程，由一个全局进程负责组织这些线程的生命周期，用户输入数据到一个特定的线程去处理生成网页返回。并发量就提上去了，这也是servlet的实现方式。
在修改数据时，经常会导致整个网页不可用。动态页面上内容多了之后，用户只想修改部分数据，但却会造成整个页面不可用，用户体验下降。对于C/S端很容易，只要起个线程去服务端请求数据，前台照样展示就可以了，等到服务端数据处理完成之后再改变前台展示。但当时浏览器里面没把这个功能开放出来，后来Netscape Navigator 2.0 首先想出了frame的解决方案，将界面分割，修改哪个界面的数据，只刷新那个界面的数据，后来被W3C采纳为HTML3.0的规范。但是此种解决方案开发量较大，需要将界面分割，并维护操作之。最好还是浏览器原生支持异步请求，1999年，微软在IE5创造了XMLHTTP ActiveX,随后被netscape，Firefox等使用。然后IE7原生支持。跨时代的AJAX就诞生了。
HTML４是1999年提出来的，现在已经过去12年了，那期间的变化如AJAX等好的用户需求解决方案也需要上升到标准，统一不同浏览器的API，提高开发效率，这也是HTML５一直在做的事情。
Flash也是对浏览器多媒体支持扩展的一种尝试，主要支持图像，视频的绘图，音频编辑以及支持如摄像头，microphone等多种多媒体外设.HTML5会将这些功能原生在浏览器中支持。
回顾WEB架构发展过程，用户需求和技术进步是推动架构做出进步的原动力。遗留系统过时的特性是架构概念的化石。一个架构不可能满足以后所有的需求，但它可以保留一定的扩展性，如HTML的设计，B/S架构的设计的扩展性是非常好的，如果每次需求变化导致架构就要做出重大改动，那么这无疑是一个失败的适应者。