RESTful架构是否适合“需授权访问的数据库型企业应用”？

划分依据一： 动作是作用在整个类型（集合，复数）之上，还是针对一个具体资源（单数）。
划分依据二： 会不会改变资源状态，把GET和剩下三个区分出来。
划分依据三： 更改资源状态的POST(create)，重复提交多次会造成问题，而PUT(update)、DELETE(destroy)就不会 －－ 称为幂等性－－ 据此可以进行安全的失败重试。

在代码组织上（及相应的URL上），传统的mvc的controller，更像是一批操作的集合（容器，分组），而REST风格的controller，本身代表一个Resource（一个名词），它具有容器的概念而且更具体，最具重要意义的是，给出了一个依据，用于将传统意义的操作集合进行进一步更细粒度的拆分，且不但不破坏其含义，反而使其意义更明确。我们做应用系统的，经常发愁的不是东西有多大，而是能不能拆分、好不好拆分，REST风格的这个依据具有全局意义，使得代码组织、维护上有了加强，实现代码更容易定位，命名上更一致。

四类操作，而不仅限于四个动作，比如将一东西另存为的操作，就属于POST（create方法）这类，可以起名为save_as，这样，就给细节设计提供了依据，同时让命名更一致。再比如激活操作，就属于UPDATE(update方法)的变种，命名还是遵循其原意activate，UPDATE的变种还可能是更新部份信息，比如只更新一个东西的状态，就叫update_status；设置一个东西为primary，可以起名为set_primary，也是UPDATE的范畴。
POST（create方法）的变种可能有quick_create等。
GET可以有index的变种（list_xxx,search_xxx,find_xxx等），当然还包括new、edit、show的变种，比如preview。

再如，一个对关联C的操作，传统方式可以在AController里定义create_c_from_b，也可以在BController里定义create_c_from_a，实现者可能随手在两者之一中实现。这样不但给维护中代码定位带来难度，而且更重要的是，在后续开发中，很难避免在不同的controller中，出现名字类似的action，实现的却是同一个功能。这种重复代码的发现和消除成本会越来越高，尤其是随着后续的功能变更，最终的方案还是回到将controller作为资源的老路上来。
我们目前使用上，并没有完全把关联的东西都作为resource，只是尽量遵循不让其产生二义性的原则。

--
以上基于rails的实现
--

类比ajax的风行是在BS模式这个大的前提不变而基础设施（浏览器的支持度、兼容性、稳定性、功能、性能）有相当大的改观及实践经验的积累之下，对javascript的一次重新审视；REST是对HTTP既定约束及HTTP协议本意的一次重新审视，从而引出的架构原则上的思考。所以无论以前开发的WEB应用，还是现在要设计一个新的WEB应用，无论设计者有没有REST思想，都要在既定约束条件下给出其解决方案；REST至少是一套靠谱的指导思想。
那些很古老的WEB应用，其REST化的程度不见得比现在的应用差，这很依赖设计者实现者对HTTP的认识程度和实现上的约束。

同意你的说法

这也正是互联网应用与企业应用的一大根本性区别，互联网是以“读”为主的应用，而企业是以为“写”为主的应用。

还不仅仅是“REST”的问题。在企业应用领域尝试折腾了几年的B/S，费了老大力气，软件质量倒是高了（重用、扩展），布署更新问题也解决了，可惜客户还是认为不好用（B/S的交互性总是不如C/S）、性能差（企业应用以写为主，缓存基本无用，sql和存储过程才够快）。有时候看看那帮傻乎乎得意的PBer们，真怀疑B/S是不是不该引入到企业应用来。

B/S就是发展趋势，如果你看了RIA应用，你会改变看法。RIA技术很好解决了楼主的问题和你的担心。RIA 必将成为企业应用开发的主流。

 

RIA直接影响的是客户端技术和体验，间接影响了整个部署和服务器端开发模式，但对解决楼主的问题一点帮助都没有。REST架构和RIA的关系是相辅相成的，而不是替代 - 严格的说，不是一个层面的东西。

不只是看，还在用。

RIA相对于C/S，最大的好处有二：一是可以单界面更新，不必像C/S要全程序重启更新；二是方便集成，可以扔到异构程序的界面里。

可惜RIA当前还是不如C/S好做啊，做一个像样的RIA界面，C/S都做出三四个来了；找一个合格的RIA程序员费的事，可以找出十个C/S程序员了。

还有一点最致命的，RIA在企业应用里跑起来比C/S慢多了（不论是客户端还是服务器端）。

事实最终会证明，“外部应用B/S，内部应用C/S”这句老俗话。

liusong1111的“三个划分依据”不错，后面的“四类动作”论述也很精彩。

我也说说自己的看法：

HTTP/REST只说过有PUT、DELETE有幂等性，多次提交是安全的；并没有说过POST没有幂等性。

HTTP将PUT定位为“Create, Update”，和DELETE一样，其URI资源指向某个实际资源，这一点是PUT、DELETE有幂等性的唯一原因；而将POST定位为“什么都可以干”，其URI指向的资源一个“万能处理器”，而非实际资源，正也因为URI指向非实际资源，所以也就无所谓幂等还是非幂等，因为其行为及幂等性完全取决于后台具体实现。

由于现实应用中Create很少在客户端指定实际资源ID（主键大多都是后台产生），因此PUT方法（URI必须指定实际资源ID）的Create功能不便使用，才借助万能的POST来充当Create功能。也就是说，POST并非先天就是只能用于Create，先天就是非幂等。

各种“RESTful” 在POST/PUT/DELETE的使用上，其实并不吻合HTTP/REST的本来意愿，也并不优雅，有点暴力，个人感觉是这类“RESTful”有异化REST的嫌疑。

我相信将动作分为四类有一定的合理性，但我觉得划分为两类（也就是你说的第二个层次）也不错:一种是GET负责读操作，总是安全的；另一种是POST负责写操作，不安全的。这种分法也完全符合HTTP/REST，而且只用到HTTP 1.0的功能，按照某位大师的说法，约束于越老的HTTP版本，越是RESTful。

 

  这里没人认为RIA和REST是一个东西，REST是一种检查规则或者规范，RIA是一种实现。我说的是用RIA可以更加容易地实现REST 的要求。另外如果单纯认为RIA只是影响客户端体验未免过于肤浅。当服务器端不希望保持状态时，那么各种状态应当保持在客户端，而RIA就是在客户端保持所有的状态，而RIA在客户端所保持的状态是一系列的客户端对象，更加有利于编程。RIA技术以客户端对象的形式保持状态对于实现REST的要求非常有帮助。

 

楼主关注的是在他提出的场景下，用REST风格去设计服务器端，我只从对外接口的角度粗暴一点说，关注的是如何实现REST服务提供者。

而我看到的RIA资料，都测重客户端实现，能跟REST沾上边的，是其作为REST消费者的架构风格。

这又是处于两个不同位置、又由同一术语牵连的话题。

你可以从回答楼主最初提出的四个问题开始，来讲讲RIA在服务器端是怎么解决这些问题的，我没有RIA实践经验。

楼主的场景就是REST不希望在服务器段保持状态，说白了就是没有Session了，那么当前登录客户的身份记录在哪里，下次请求时如何知道他是谁的问题！另外就是同一个登录客户的两个页面交互数据怎么办？以前有一种办法是把这些数据放在session里面，现在没有了session 不好办了。那么RIA技术可以在客户端以对象形式保持状态，包括客户的身份。而两个窗口之间交互数据在客户端可以非常轻松地完成，根本不需要关心后台。
采用RIA技术，无论要Post还是GET,你只需向后台发送HttpRequest调用后台提供的Httpservice就可以了，根本不需要服务器段保持任何客户端状态。不知道这样是否对楼住的问题所有帮助。

RIA提供事件机制能很好解决httprequest调用之间协同。其实客户端很少有事务的概念，只是若干请求之间的协同工作罢了。

所以，采用RIA技术，你可以把服务器端设计成完全的HttpService或者Webservice,因为前端和后端只交互数据，这些数据的格式可以是xml，也可以是RIA规定的某种序列化后对象。

关于RIA技术，这里我指的是FLex对REST支持的讨论可以见这边文章 。
http://www.fngtps.com/2007/06/flex-can-t-do-rest

标题是FLEX不能实现REST，但后面的评论认为是标题党，也有人说rail不是完全的RESTFUL,大家看看吧。
就是否完全完全RESTFUL，我个人认为，企业应用没有必要完全RESTFUL，因为企业应用关注的核心不是技术，而是是否易用，易维护，易集成，以及设计是否考虑得比较全面等。

还可以看看
http://www.infoq.com/cn/news/2007/12/top-10-flex-misconceptions