REST+RIA方案

>>问题是一个大flash或者完全的spa，其实实际效果都并不好。所以要合理规划。

你说的对。我们现在常用的做法是，一个controller对应一个flash，目前还没有发现这种做法有什么明显的问题。在更大范围内应该如何组织应用结构，这也是我正在思考的问题。


>>h-t-t-p500（javaeye识别url存在问题）或者进度条假死，这些是设计和实现是否周到的问题，不是架构的问题。Ajax当然也可以有很好的错误处理。还有，初次下载的时候，你的服务器死了，就算flash，不一样404嘛。

开始时出错还是中间出错，影响用户的程度还是差别很大的。开始时用户还没有什么实际的操作，出错也不会有严重的后果，但是操作进行到一般时出错就麻烦了。在论坛上发表一个长贴，提交时却出错，结果辛辛苦苦敲的东西全没了，这种事情我们都遇到过，对不对？
Ajax能处理错误是肯定的，但你终究还是要处理。处理错误从来就是编程中的大难题，不是一句“能够处理错误”就可以解决的。而Flex的好处就在可以根本不必考虑这个问题，不管客户端跟服务器之间出什么通信故障，你在客户端的数据总是好端端的保存在自己那里，不会凭空消失。

>>你这种观点不公平。

我知道你会这么说。事实上我前面这段话确实不公平，为什么呢，因为我觉得你批评厂商盲目推出新功能这样的说法已经不公平了。拿现在这个例子来说，ROR不是标准。REST已经是一个可用的规范，但也不是w3c的标准。RIA根本还没有一个标准。你要我怎么办呢？是不是该停止开发，等w3c推出相应的标准以后，再来跟进？

要是我没记错，HTML 4.0规范是1998年推出的，那时候IE的市场已经占到70%以上，且IE和NN的接口已经完全是分道扬镳了。

我也不同意你说当时的开发者是愚昧可怜的，当时的人们并不比现在的我们更笨。你需要看他们是在什么样的一个历史背景下，那时候是Internet的大泡沫时代，似乎和.com概念沾边的都会一夜暴富，投资者要求网站马上上线，否则就可能错过机会，而大部分开发者是从C/S转过来的，根本对Web是什么还没有一个清楚的概念，怎么在一个月内作出一个完整的网站？包括IE和NN的开发者都承受着这样的压力，坐下来等着w3c的规范实现在当时是根本不能接受的办法，最简单的办法就是最奏效的，即使你站在今天的角度觉得反过来更加合理。

你觉得从前的开发者愚昧而可怜。那么10年以后，说不定也会有人指着我们的鼻子这么说：你瞧，当初的人是多么愚昧可怜啊！谁都不能超越历史的局限，以前的开发者并不笨，他们只是受迫于疯狂的大环境而已，还是对他们宽容一些吧。

>>何必扯着REST呢? 用更简单更高效的实现方法就行了啊!

软件开发是需要权衡的。如果效率是压倒一切的要求，那么诚如你所说，用最简单的办法最好。但是现实应用中通常还要考虑其他的问题。我已经分析过使用REST会带来什么利益，至于这些是不是符合项目的实际要求，当然要你自己来决定。我并不认为在所有场合都应当使用REST。

事实上Ajax是会好好保存在那里。过去提交失败而找不回来（如臭名昭著的csdn blog系统）多是传统web表单提交，而且归根到底是开发者的失误。

当然Ajax用的不好，也能丢失的（例如我完全忽略错误，直接进入下一步），正如Flash用的不好，也能丢失的。问题在于人，人有没有处理错误的意识。

真这么牛干嘛还要等ActiveResource成熟，自己写啊！老跟在人家屁股后面不好！

呵呵，这就是世界上轮子很多，但是真正非常圆，满足实用需要的轮子很少的原因。
为何不问楼主：既然这么牛，为何还要用Rails、Flex？

楼主又没说Rails、Flex不好，呵呵。他把在这上面做的尝试拿出来共享，不管效果如何很值得鼓励！
只是你如果发现ActiveResource不成熟，完全可以自己去改进，但没要你去从头再写一套啊。希望你也把你改进心得拿出来和大家共享一下！