Ajax、REST，Web开发的十字路口

断断续续花了好几个小时才看完fins的 "JSF 与 "我的伟大发明" ---- 关于B/S UI开发的胡言乱语"
http://www.javaeye.com/post/523520?page=1
帖子中的大论战，感觉有一点观点是需要双方都明确的，那就是Web开发目前正处于一个分歧点上：

是继续坚持传统的Server Rendering的架构模式？
还是开始转向到客户端、服务器端完全分离的架构模式？

我喜欢把这种客户端、服务器完全分离的模式叫做BC/S（基于浏览器的C/S）模式，当然，跟fins所说的"以数据为中心的B/S模式"应该是一个意思的，只是更简短，而且我觉得更能描述出这种架构的特色，那就是像C/S一样，有一个独立的客户端C（甚至也许能把这个C单独发布，允许它连不同的Web Server来使用，不敢想了，能产生的新的应用方式）。

然后切入正题：为什么要这样做？为什么会是现在？

因为Ajax和REST。REST是Web协议HTTP、URI背后的设计原理，只是直到2000年才被Roy Fielding在博士论文中正式命名提出来。

但是在Ajax出现以前，浏览器的功能相对比较弱，只能实现一些瘦客户端的功能，因此，Web应用的开发者们只能把功能的实现尽量向服务器端移，这样产生了现在被广泛使用的WebMVC架构模式。这样做，其实有很多地方已经违反了REST的架构约束，但在当时是没有办法的事，REST对客户端有更强的能力要求，REST的思想在当时也不为人知。

Ajax出现后，浏览器的能力大大增强了，这时依靠Ajax的能力真的有可能完全遵从REST的架构约束了，这就需要把许多功能前移，建造更强大的客户端了。这也许就是为什么REST会随着Ajax的出现而渐渐流行开来的原因，当然，Rails DHH的大力推广也有功不可没。

因此，基于以上原因，我感觉我们Web开发人员被推到了需要选择的十字路口，是留守传统模式，还是开始实践新的模式？传统模式已经有了这么多年的投入，各方面都已经比较成熟了，开发效率已经到了一个比较高的水平；而BC/S模式给人的感觉是更自然，更清晰一些，但在上面积累的开发经验还不够，需要大胆地开疆拓域。

认同LZ观点,
请谈点具体的吧!
具体怎么做?
有什么工具可用?
运行的时候是什么样的流程?
现在起步首先要做什么工作,完成那些模块?

我也正在实践这种架构模式，我想你应该比我有经验吧！
我只是觉得论战双方有点没有认识到对方所处的立场，因此提出来点明一下而已。
至于方案嘛，我准备基于Ext来构建客户端，还得把Ext研究透了，才能实现界面随心所欲的灵活性。
看中Ext是因为它提供了一种界面描述语言，比HTML强大，比XUL、XAML简单。
服务端准备采用能支持REST的几种框架：Rails、Restlet、Django
因为成熟度与开发效率，先从Rails开始，但要裁剪掉它的View层。
至于工具嘛，推荐两本书吧：《RESTful Web Services》和《Ajax设计模式》
前一本相当于REST的圣经，同时也讲了很多Rails的实践；
后一本是Ajax的百科全书，讲了多达70种的Ajax模式。
运行的时候主要是客户端来控制程序的流程，只要运用Ajax那些模式就可以了。
起步要做的还是学习加实践啊！先把界面做出来吧，遵从敏捷原则，让它尽快能跑起来，
然后再慢慢重构。

问题是Ajax等的是开放的技术，
JavaScript更是彻底的开源技术
一旦铺开来
各大server厂商短期内捞不到什么好处，或要改变策略
也许看法有点悲观
但如果能自己能对技术充分把握，自由选择，这是很会幸福的：）

用自己的ajax，让大厂商继续折腾去吧

恩！
一句话
代码说话

一句话 科技以人为本

代码还一行没有
很多东西，像Ext和Ruby/Rails都要重新学
又想试验我自己的新的分层的想法
万事开头难，到周末看能不能拿出一个能跑的代码吧

翻Matt Raible(AppFuse作者)的帖子时无意中发现了这个：
The Thin Server Architecture Working Group
http://java.dzone.com/news/thin-server-architecture-worki
瘦服务器架构，看来给新架构命名的工作在国外正开展得如火如荼了！

今天看到Adobe的宣传。它们提出ＳＯＣ＋ＳＯＡ的概念。客户端是跑在浏览器里的Flex写的Flash swf。服务器端入口是它们的LiveCycle DS服务。这个后边接SOA的Web Service。恐怕是最符合你这个BC/S的概念了。