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

Flex对REST的支持，是对它作为REST消费者的支持。
技术正是“易用，易维护，易集成，以及设计是否考虑得比较全面”的一个重要基石，何况REST更像是专门为了达到这些目标的指导原则。不然，就有点像“人不应该去吃东西，而应该关心自己怎么活下去”。
当然，我看到你上面的“完全”两字，十分赞同，如果只为了技术而技术，就应该是信仰偏好方面的东西了，这种极端之美，是扭曲的，不是客观之美。

哪些数据由RIA（客户端）持有，及协调其与服务器端数据的关系，以及安全等，是个系统工程。

上面的例子，过多以REST消费者或REST接口的便捷性考虑问题了，回避了很多 REST风格对服务器端设计的冲击，及服务器端固有的复杂性和基础设施固有的约束。

REST的一个URI多format的风格，HTTP很早就支持了，只是应用场景的不成熟（对比现在facebook、amazon等一批集成平台的火爆）和实现技术的障碍（rails还算不错，以前看过的java支持度挺差劲）。这也算是时势造技术的典范吧。

看来真得找时间好好学习这个论文了，何况有很好的中文版。
对leebai前面的回复完全赞同。
对于数据密集型的应用，正是REST发挥作用的地方。反倒是流程密集型的，比如用工作流引擎驱动的企业应用，我还想不清楚REST能带来多少好处。
根据sslaowan上面分享的，一个数据密集型的应用，按 服务+操作 的方式划分，与 按 资源+动作 的方式划分，哪个能做到更直观，粒度更细，更无二义性呢？我倾向于后者。

REST使用有多方便？REST跑得有多快？REST真的能很方便地异构集成吗？

认真实践过，老老实实回答这几个问题，再考虑是不是要用到企业应用。

第三个问题，REST的本意及重点不是做异构集成，让异构集成更清晰简单只能算它的副产品，或HTTP本来就有的能力。
企业应用需要异构集成的可能性相对较大，其范围、粒度和性质都确定后，REST是一种可选方案。这时更多关注的不是对内部实现的影响，而是API接口的考究。
除去其主要目的是做异构集成的情况，REST对于WEB开发仍有极重要的指导意义。这时第二个问题就不是问题。

我以前也怀疑过四个动词不够plain old，也认为GET/POST足够。在后来的使用过程发现，由四个动词衍生的7个方法（create,update,delelete,index,show,edit,new）及它的变种能覆盖的操作超出之前的预期，而这7个方法对命名的统一有很大好处，甚至对javascript的function命名有指导作用。

从实现角度说，以我一年前对java框架的探索看，RESTful的支持都不好，有框架和语言两方面的问题，总之如果因此引入的附加复杂度足以抵消带来的好处的话，不完全RESTful就是明智之举，这方面没有经验。

相对来说，REST更适合Web网站一些，因为Web网站需要享受更多的Web好处。REST带来的主要好处就是可以充分利用WWW缓存，这样就使一台普通服务器也能背得起有大量人访问的网站。这就是Web的主要好处，让Web能够迅速蔓延到全世界的每个角落。

另一方面，REST应该也能适用于企业，因为它还能带来其他好处，比如简单且恒定的URL、简单且标准的Web Services、以资源为中心的架构设计等。这样的架构天生就是SOA的，但又不同于RPC风格的Web Services，被称作RESTful Service。以资源为中心也能够简化设计，统一程序接口以提高产品质量，但需要我们转换思维方式，从以动词为中心的思维方式转换到以名词为中心的思维方式。

你提出的几点：

1、REST的服务器无状态性，要求客户端保持应用的状态，服务器只保存资源的状态。这样用户名、密码应该由客户端保持，每次提交请求时都需要提供完整的信息，包括用户名、密码。

2、企业应用是有很大部分用不到Web的缓存优势，但只要有public的资源，这些资源就能够享受到Web缓存的好处。

3、资源是那种概念上原子性的东西，比如一篇发帖、一篇回复、一篇blog等；或者复合起来的，比如一整篇帖子（包括所有回复），这样的概念上独立、能单独拿得出来的东西。

4、向服务器发PUT请求来改变资源的状态时，可以把资源的属性和它附属资源的属性都放在请求body里，这样服务器可以一次更改多个资源的状态。也可以每次更改单个资源的状态，由客户端来控制Transaction，不过这样做现在还比较难，客户端没这方面的基础设施。

另：建议开个讨论架构/思想的专版，现在的架构越来越不依赖于具体技术了。

1 从我的研究来看，企业应用中无非就是业务对象（数据），业务流程，业务规则，业务操作（服务）这些东西，不同的方法论，以及不同实践经验的专家对于这些内容的倾向性不同。在Ajax and REST那本书里，将ROA和以数据库为中心视为同属于以数据为中心阵营，将Web Server看成一个巨大的数据库，然后HTTP协议提供标准CRUD操作接口。而从Fielding论文出发，我更以为ROA与OO是一个阵营的。在IBM的BPM体系中，把业务对象这些东西都定义为Resource，我觉得也是这个道理。资源是抽象程度更高的对象，业务对象（对象中的实体）可以成为划分资源颗粒度的依据。而HTTP操作，应该就相当于实体对象持久化。我想这是REST与企业应用结合的一个点。

2 关于流程密集型，我觉得所谓Workflow或BPM引擎，是SRP，关注点分离，和软件复用等软件工程思想的结晶。这样考虑，流程与服务，资源等概念是一个闭环系统。我觉得IBM的BPM在Big Web Service方面的架构，已经将其融和起来了。我写了篇论文是讲如何借助REST将RESTful Web Service与BPM融和起来。

3 关于Web与企业应用，我觉得这也代表了两种不同实践经验的专家看问题的出发点。Web的出现是为了信息共享，后来延伸到企业应用，这个阵营的人看问题，是以Web作为前端，Application作为后端，所以他们看到的是一个大大的Web，和一个小小的Application，因此当Application变得超出了他们想象的大后，就认为其复杂程度超过了其本身；而企业应用专家，是以Application为前端，Web为后端，从Application--->Web的方向看问题，Web只是一种表现层，所以是一个小小的Web，一个大大的Application。而企业应用专家又分为两大阵营，像J2EE，.Net这个圈子里的人认为应使用高级语言来搞定业务，数据库只是持久化的一种手段，可以用flat file，LDAP，Stream等其他手段替代。而数据库阵营则认为企业应用的核心是数据库，这就又回到我说的第1个问题上去了。

     在做项目时，总是在和持不同观点的人争论一些问题，我思考很长时间，为啥大家会有这么大的分歧，以上是我的一些体会。

我觉得如果把企业应用集成，甚至于服务科学的n多问题考虑进去，那么REST就将变成另一个WS-*规范，简单，方便性毫无可言了

大家对REST的兴趣越来越大了。

目前正在用django+extjs做一些REST的尝试。我赞同clia的说法，相信在企业应用中可以起到好的效果。

在我的印象中,
REST是Web Service的一种实现风格.另外一种实现风格是以SOAP为代表的XML RPC之类的技术规范.
Web Service 的实现风格可以分为两种 :
(1) RPC风格 (远程调用风格,XML格式的),以SOAP为代表
(2) REST

PRC风格的问题在于多了一个信封,把地址,服务名什么都包在信封里面.因此是 Not Proxy Friendly.
Proxy无法在URL的级别,判断客户需要的服务.必须要一个协议解析器(比如,SOAP协议)看到信封的里面,才能够发现需要的服务.
REST风格就解决了这个问题, 需要什么服务,都写到URL里面.

如果我的记忆和理解都没有错的话.我就继续下面的猜想.

--------------------------------------------------

RPC和REST这两种风格都注定只是过渡产品.

(1)
RPC风格,用XML表达函数名(服务名),返回值,参数列表,数据类型.非常蹩脚
XML就不是干这个的,XML是用来描述结构化层次数据的,尤其是树形结构数据.
XML用来表达函数调用的语义,就非常不是当了.
Spring的问题也在于此.如果Spring的配置文件格式不用XML,情况就会好得多.
XML承担了太多本来不属于它,不适合它的工作.

Web Service RPC风格的最终载体,我猜想,还是脚本.很可能是JavaScript.
因为JavaScript已经非常通用了,大量用在Web Page中,有很多各种平台的解析器.
从Ajax的发展,已经可以看出来了.

(2)
REST风格的要点,在于通用查询语句.
一条URL作为查询服务地址,查询条件,然后返回一系列数据(返回的数据同样包含了服务地址和查询条件,比如 ID, Name之类的).

我们可以把 REST服务器看作是一个数据库.可以是XML文档数据库,也可以是关系数据库.
不过,REST服务器表达关系数据服务有点力不从心. SQL太复杂了.
REST服务器非常适合表达XML文档数据库. XPath天生就是用在URL中的.

从这点来看, REST服务并没有提供更多的超出XML文档服务器的工作.
而且,REST也远远达不到语义网所描述的目标.
REST的主要意义,可能就在于打破人们对RPC风格的迷信.

--------------------------------------------

REST风格是否适合"数据型企业应用".
如果查询条件简单的话,当然适合.而且非常适合.REST就是干这个的.
如果查询条件非常复杂,就不适合了.
授权不是问题,那只是多了一个验证, HTTP Header里面一个SessionID传来传去足矣.

业务流程复杂的企业应用,就只能采用RPC风格了.

----------------------------------------------

关于RIA,如果还是基于浏览器.我猜想,也只能是过渡产品.
浏览器里面的RIA,再RICH,也RICH不过本地运行的客户端程序.
Web Service Smart Client之类的东西,还稍微有点前途作为什么云计算的客户端.

浏览器会不会荒废?不会.
浏览器以后可能会作为最主要的界面展现器.
以后的本地客户端程序中,会嵌入浏览器. 而不是浏览器中嵌入RIA.

上述这些都是瞎想.

你确信自己读懂了论文的原文了吗？

你确实在绝大多数时间都很自信，我就不在这里打击你的自信心了。按照你的个性，在这里交流很容易变成吵架和闹意气。

如果对REST真的有兴趣，加我的MSN吧：unruly_wind at sina dot com，我们私下深入交流一下REST相关的问题。另外也可以来这里交流：
http://groups.google.com/group/rest_in_action


你啊，总是这么着急。这本书才读完了序言，就开始下结论了。慢慢来，兄弟！