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

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

 

首先，定义一下“需授权访问的数据库型企业应用”：其实也就是大多数（绝大多数？）j2ee开发人员要面对的那种应用，数据存储是一堆业务表，表的域比较多，表之间有关系；业务逻辑比较多，一部分是简单的增删改查，一部分是由简单增删改查组合而成的复杂操作，进入系统之前必须登录，只有授权的用户才允许进行业务操作（包括查看）。

 

REST、RESTful的资料看了一些，总感觉RESTful并不适合这类应用,主要依据是：

 

1、这类应用session（及背后的cookies）是必须的，服务器端多少会有一些会话State（比如"用户名"），肯定要违背REST服务器Stateless 原则。

 

2、这类应用任何Proxy Cache(及其他服务器之外的Cache)都是不允许的，因为非授权用户不可访问任何信息，因此无法利用REST强调的Cacheable优势。

 

3、这类应用面对的“数据对象”和REST中的“Resource”应该是不同的，后者偏向于表达那种无结构的对象（比例文档，图片，音视频），对其进行的操作绝大多数时候针对对象整体(既操作本身不关系对象内部的数据构成)，因此可以用POST/GET/PUT/DELETE(CURD)等四个基本动词来表达；而前者大多数情况下，是复杂的、结构化的对象，对他们的操作除了整体操作，还有很多针对其局部的操作（既操作涉及对象的内部结构），四个基本动词远不够用，在不扩充动词的情况下，只能让一个动词表达多个操作，这种设计并不符合REST简单优美的声誉。

 

4、这类应用的“数据对象”之间很多时候是相关的，对某个对象的CURD操作经常同时需要对其他对象的CURD操作，如果把这些相关操作（2个以上）放在一个HTTP请求中完成，则使用四个基本动词来表达是语义不确切的；如果把这些相关操作分成多个HTTP请求，则相关操作的Transaction是无法保证的。

 

上面四点中，1、2对REST的违背是很明显的，3、4也很容易看出来，我的问题是，难道RESTful架构并不适用主流的企业应用（非企业“级”应用:-)），而只适用于像Javaeye这样的向公众提供信息服务的“资源型”网站？

 

另外还有几个主题之外的RESTful疑问，一并请教：
a、现在很多论坛有一个功能：必须回复才能看到主帖，但看到和看不到时的访问URI是相同的，这种设计是否违背REST？
b、基本上论坛帖子都有访问次数统计，其实就是GET操作的时候改变了服务器State，应该也是违背REST吧？
c、只使用POST/GET是否也能实现RESTful？我看Fielding的论文中并没有提到必须使用PUT/DELETE。
d、在《RESTful Web Services》的序言中，作者写道：

 

In that first version of HTTP, cleverly disguised as a lack of features, we can see addressability and statelessness: the two basic design decisions that made HTTP an improvement on its rivals, and that keep it scalable up to today’s mega-sites. Many of the features lacking in HTTP 0.9 have since turned out to be unnecessary or counterproductive.Adding them back actually cripples the Web. Most of the rest were implemented in the 1.0 and 1.1 revisions of the protocol.
 
HTTP的第一个版本（指0.9），被聪明地伪装成功能简陋，我们可以看到可寻址性和无状态性，这两个基本的设计策略使得HTTP优于它的竞争对手，并使它在可扩展性方面能够适应今天的百万级站点。HTTP0.9中缺少的很多功能，大多数都在1.0和1.1版本中被实现，后来反而成为不必要的或者反生产力的，加上它们实际削弱了Web。

 
作者的意思是不是：POST/PUT/DELETE等其实都不是RESTful的本质，只有 GET+URI 才是RESTful的核心战斗力？

 

最近为了升级7wxAop框架(自用+开源)的后端基础结构，花了很多时间做技术准备，以上是调查REST时的疑问，请这方面有经验的同学参与讨论解惑。

REST话题没有专版，不知道该发何处，先放在人比较多的JAVA版:-)。

评论

43 楼 liusong1111 2008-05-07  

ltian 写道

buaawhl 写道

在我的印象中,
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.

上述这些都是瞎想.

客户端嵌浏览器？？？？？真是大胆的想法？有什么好处呢？客户端的部署安装传统方式去部署吗？ 
那还要里面嵌浏览器干什么，为了上互联网？还是有什么其它意想不到的需求？

传统的桌面程序也有较WEB开发不便的地方，比如流式布局。甚至用嵌入式的浏览器去做比现在称为mashup的粒度更粗的集成。

42 楼 leebai 2008-05-07  

<div class='quote_title'>dlee 写道</div>
<div class='quote_div'>
<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>Transfer是不是翻成“传递、传输”更好点？ <br/><br/>我仔细检查了Fielding论文第5章对REST的描述，发现作者所描述的信息流动都是单向的，既，"表象状态RES"总是从服务端到客户端（中间可经过多层），也就是GET经历的过程；该章内容并不涉及“state”本身在服务器上的“变更（或迁移，Transfer的另一个意思）”。 <br/><br/><span style='font-size: medium;'>[size=small;]补充：又看了一遍原文，基本确定dlee对“REST”的“T”的翻译是有问题的，Transfer就是指“状态”（或称信息、数据、资源 。。。Hypertext*）的“传输</span>”，和HTTP的第三个T是一样的内涵，The Hypertext Transfer Protocol (HTTP)译为“超文本传输[/size]协议”，Representational State Transfer (REST)没有理由译成“表述性状态转移”。这么翻译有可能导致人们对REST的误解，以为REST描述的是“状态变更”问题。 <br/><br/><br/><span style='font-size: small;'>继续补充：刚发现dlee在译文中（6.5.3小节），居然认为HTTP的传统翻译“超文本传输</span>协议”不对。真是太荒谬了。看来经验再丰富的老手，也有糊涂的时候。</div>
<br/>你确信自己读懂了论文的原文了吗？ <br/><br/>你确实在绝大多数时间都很自信，我就不在这里打击你的自信心了。按照你的个性，在这里交流很容易变成吵架和闹意气。 <br/><br/>如果对REST真的有兴趣，加我的MSN吧：unruly_wind at sina dot com，我们私下深入交流一下REST相关的问题。另外也可以来这里交流： <br/><a href='http://groups.google.com/group/rest_in_action' target='_blank'>http://groups.google.com/group/rest_in_action</a> <br/><br/>
<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>作者的意思是不是：POST/PUT/DELETE等其实都不是RESTful的本质，只有 GET+URI 才是RESTful的核心战斗力？</div>
<br/>你啊，总是这么着急。这本书才读完了序言，就开始下结论了。慢慢来，兄弟！</div>
<p>真把你招来了，呵呵。</p>
<p> </p>
<p>这个地方你确实错了，而且错得离谱。你先别急，我慢慢给你解释：</p>
<p> </p>
<p>1、先说技术层面。你再仔细看看6.5.3小节的内容，作者在这里强调的是:<span style='color: #ff0000;'>不应该为了能够穿过防火墙，就把HTTP仅仅当作“搬运工具”。既：不要只看到HTTP能够把一个东西从A处搬运到B处的能力，而忽略了HTTP搬运的方式和过程(比如协议头标对“中间组件”【防火墙proxy等】在传输过程中的指导作用)</span>。如果只是为了“搬运”(如SOAP over HTTP),就会忽略各种“中间组件”的作用，并且破坏防火墙的实际作用，如果仍期望防火墙起作用，其厂商就要增加额外的过滤（既阻止SOAP这样借壳上市）。</p>
<p> </p>
<p>总的来说，作者是在强调:<span style='color: #ff0000;'>HTTP的“传输行为本身”比“传输所达到的目的”更重要</span>。</p>
<p> </p>
<p>2、再说英语语言层面。在英语中，transport和transfer都有“<span style='color: #ff0000;'>传输</span>”的意思，但<span style='color: #ff0000;'>transport只是及物动词，transfer既可是及物动词也可是不及物动词</span>，所以英语要表达“某某东西的传输协议”，正确的<span style='color: #ff0000;'>语法</span>就是： Something Transfer Protocol,HTTP,FTP,SMTP,NNTP都是如此（如果要用transport，只能说Something transported Protocol），所以，之所以HTTP是 HyperText Transfer Protocol，<span style='color: #ff0000;'>并非因为你说的Transfer还有“转移”的意思，而是因为它可用做不及物动词</span>。<br/>如果你按你的翻法，FTP成了“文件转移协议”，SMTP成了“简单邮件转移协议”。。。整个互联网行业非崩溃了不可。。。。</p>
<p> </p>
<p>译文中凡是出现“转移”的地方，你自己读起来不觉得别扭吗？</p>
<p> </p>
<p>总而言之，你这个“<span style='color: #ff0000;'>HTTP并不是一种传输协议</span>”的论调真是吓死人了，玩笑开大了，呵呵。</p>
<p> </p>
<p>当然，你们所作的工作我还是很佩服的，开发社区也应该感谢你们付出的劳动。MSN加你了，很喜欢和你讨论问题，虽然你认为我固执。</p>
<p> </p>

41 楼 leebai 2008-05-07  

<div class='quote_title'>buaawhl 写道</div>
<div class='quote_div'><br/><br/>RPC和REST这两种风格都注定只是过渡产品. <br/><br/><br/></div>
<p> </p>
<p> 赞成从更高的角度看问题，要想找更好的方案，就得跳出现有的所有框框。</p>
<p> </p>
<p> </p>

40 楼 dlee 2008-05-07  

leebai 写道

Rails &ldquo;其实不是4个动词，而是4类动词&rdquo;，这个能接受一点，还是有点晕： 把动词分成4类，在架构上有什么特别意义？

REST叫做&ldquo;带表象的状态迁移&rdquo;，动词的分类是因为这4类操作会对资源的状态带来不同的影响，造成状态的迁移。

GET 不影响资源的状态
POST 创建一个新的资源
PUT 修改一个资源的状态
DELETE 删除一个资源

所以这4类操作给资源状态迁移带来的结果是不一样的。

Transfer是不是翻成&ldquo;传递、传输&rdquo;更好点？

我仔细检查了Fielding论文第5章对REST的描述，发现作者所描述的信息流动都是单向的，既，"表象状态RES"总是从服务端到客户端（中间可经过多层），也就是GET经历的过程；该章内容并不涉及&ldquo;state&rdquo;本身在服务器上的&ldquo;变更（或迁移，Transfer的另一个意思）&rdquo;。

[size=medium;] [size=small;]补充：又看了一遍原文，基本确定dlee对&ldquo;REST&rdquo;的&ldquo;T&rdquo;的翻译是有问题的，Transfer就是指&ldquo;状态&rdquo;（或称信息、数据、资源 。。。Hypertext*）的&ldquo;传输[/size]&rdquo;，和HTTP的第三个T是一样的内涵，The Hypertext Transfer Protocol (HTTP)译为&ldquo;超文本传输[/size]协议&rdquo;，Representational State Transfer (REST)没有理由译成&ldquo;表述性状态转移&rdquo;。这么翻译有可能导致人们对REST的误解，以为REST描述的是&ldquo;状态变更&rdquo;问题。


[size=small;]继续补充：刚发现dlee在译文中（6.5.3小节），居然认为HTTP的传统翻译&ldquo;超文本传输[/size]协议&rdquo;不对。真是太荒谬了。看来经验再丰富的老手，也有糊涂的时候。

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

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

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

leebai 写道

作者的意思是不是：POST/PUT/DELETE等其实都不是RESTful的本质，只有 GET+URI 才是RESTful的核心战斗力？

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

39 楼 buaawhl 2008-05-07  

在我的印象中,
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.

上述这些都是瞎想.

38 楼 fangzhouxing 2008-05-07  

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

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

37 楼 sslaowan 2008-05-07  

lgx522 写道

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

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

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

36 楼 sslaowan 2008-05-07  

liusong1111 写道

sslaowan 写道

rain2005 写道

引用

但REST论文中的Resource确实是指页面、图片之类的HTML相关文档，我关心的是这个概念是什么时候、被什么人扩大为"各种东西"

,那篇论文看得有点晕，可以看看江南白衣的博客有篇REST的文章或者是AJAX模式与最佳实践比较好理解一点。

Second, there exist many addresses that corresponded to a service rather than a document — authors may be intending to direct readers to that service, rather than to any specific result from a prior access of that service.（6.2.1 Redefinition of Resource）
存在着很多地址对应于一个服务，而不是一个文档——创作者可能是有意将读者引导到那个服务，而不是引导到来自预先访问那个服务而获取到的特定的结果。
REST达到了这个目标，通过将一个资源定义为创作者想要标识的语义，而不是对应于创建这个引用时的那些语义的值。然后留给创作者来保证所选择的这个标识符确实真正标识出了他所想要表达的语义。

我觉得资源是什么，Fielding论文中这一段已经说得很明白了，资源的概念类似于对象，对象包括服务，实体，值对象（Evans的分类）

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

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个问题上去了。

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

35 楼 clia 2008-05-07  

leebai 写道

REST、RESTful的资料看了一些，总感觉RESTful并不适合这类应用,主要依据是：

1、这类应用session（及背后的cookies）是必须的，服务器端多少会有一些会话State（比如"用户名"），肯定要违背REST服务器Stateless 原则。

2、这类应用任何Proxy Cache(及其他服务器之外的Cache)都是不允许的，因为非授权用户不可访问任何信息，因此无法利用REST强调的Cacheable优势。

3、这类应用面对的&ldquo;数据对象&rdquo;和REST中的&ldquo;Resource&rdquo;应该是不同的，后者偏向于表达那种无结构的对象（比例文档，图片，音视频），对其进行的操作绝大多数时候针对对象整体(既操作本身不关系对象内部的数据构成)，因此可以用POST/GET/PUT/DELETE(CURD)等四个基本动词来表达；而前者大多数情况下，是复杂的、结构化的对象，对他们的操作除了整体操作，还有很多针对其局部的操作（既操作涉及对象的内部结构），四个基本动词远不够用，在不扩充动词的情况下，只能让一个动词表达多个操作，这种设计并不符合REST简单优美的声誉。

4、这类应用的&ldquo;数据对象&rdquo;之间很多时候是相关的，对某个对象的CURD操作经常同时需要对其他对象的CURD操作，如果把这些相关操作（2个以上）放在一个HTTP请求中完成，则使用四个基本动词来表达是语义不确切的；如果把这些相关操作分成多个HTTP请求，则相关操作的Transaction是无法保证的。

REST话题没有专版，不知道该发何处，先放在人比较多的JAVA版:-)。

相对来说，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，不过这样做现在还比较难，客户端没这方面的基础设施。

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

34 楼 liusong1111 2008-05-07  

lgx522 写道

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就是明智之举，这方面没有经验。

33 楼 lgx522 2008-05-07  

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

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

32 楼 liusong1111 2008-05-06  

sslaowan 写道

rain2005 写道

引用

但REST论文中的Resource确实是指页面、图片之类的HTML相关文档，我关心的是这个概念是什么时候、被什么人扩大为"各种东西"

,那篇论文看得有点晕，可以看看江南白衣的博客有篇REST的文章或者是AJAX模式与最佳实践比较好理解一点。

Second, there exist many addresses that corresponded to a service rather than a document — authors may be intending to direct readers to that service, rather than to any specific result from a prior access of that service.（6.2.1 Redefinition of Resource）
存在着很多地址对应于一个服务，而不是一个文档——创作者可能是有意将读者引导到那个服务，而不是引导到来自预先访问那个服务而获取到的特定的结果。
REST达到了这个目标，通过将一个资源定义为创作者想要标识的语义，而不是对应于创建这个引用时的那些语义的值。然后留给创作者来保证所选择的这个标识符确实真正标识出了他所想要表达的语义。

我觉得资源是什么，Fielding论文中这一段已经说得很明白了，资源的概念类似于对象，对象包括服务，实体，值对象（Evans的分类）

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

31 楼 liusong1111 2008-05-06  

ltian 写道

楼主的场景就是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

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

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

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

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

30 楼 sslaowan 2008-05-06  

rain2005 写道

引用

但REST论文中的Resource确实是指页面、图片之类的HTML相关文档，我关心的是这个概念是什么时候、被什么人扩大为"各种东西"

,那篇论文看得有点晕，可以看看江南白衣的博客有篇REST的文章或者是AJAX模式与最佳实践比较好理解一点。

Second, there exist many addresses that corresponded to a service rather than a document — authors may be intending to direct readers to that service, rather than to any specific result from a prior access of that service.（6.2.1 Redefinition of Resource）
存在着很多地址对应于一个服务，而不是一个文档——创作者可能是有意将读者引导到那个服务，而不是引导到来自预先访问那个服务而获取到的特定的结果。
REST达到了这个目标，通过将一个资源定义为创作者想要标识的语义，而不是对应于创建这个引用时的那些语义的值。然后留给创作者来保证所选择的这个标识符确实真正标识出了他所想要表达的语义。

我觉得资源是什么，Fielding论文中这一段已经说得很明白了，资源的概念类似于对象，对象包括服务，实体，值对象（Evans的分类）

29 楼 liusong1111 2008-05-06  

ltian 写道

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

对于既定的业务功能，用REST风格去想，会关注整体URL的规划（有哪些resource，各暴露哪些动作），及各个URL的设计（URI，parameters，headers，representations）。所有这一切，都应基于业务功能的约束，所设计的用户交互的约束。
关于事务，比如，典型的银行转帐的动作，无论要不要REST，都是一个动作，都不应拆成加A和减B两个。即，REST不是强行把有业务意义的原子拆分。
除非，当拆成两个时仍有其业务含义。
有时，在一个页面聚合多个资源信息时，这种拆分却是很有意义的 -- 这是只读（GET）场景，同时是以实现角度影响了业务模型的细节 -- 比如用ajax或RIA加载的数据片段仍有其业务含义。

28 楼 liusong1111 2008-05-06  

ltian 写道

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

session/stateless：web生来就是做共享文档用的，甚至url和文档物理地址都是一一对应的，那时压根就没考虑状态是干啥的。谁知道后来那么多人欣赏这么简易的玩意，在服务器上弄个CGI居然就拿它做应用，鼓捣个session就假装它有状态了，依我看session只是对HTTP的一个workaround，它本质不就是状态放在服务器端，把它的key在服务器端和客户端传来传去吗？（把key弄的特随机特长，假定别人猜不到；并结合session失效等机制保证其安全）

无状态的好处？
直观性：不希望被人说，这个URL很丑，很晦涩。在对URL的设计上，可以更清晰/显式的体现输入（http parameters,headers）输出（若干representation）的概念。
可伸缩性：显然如果把状态放session里，又如果session放内存里，水平扩展时session复制是个麻烦事。
缓存：基于URL的缓存很吸引人，充分利用HTTP的缓存支持能力很好很强大。

注意：前提是不改变既定功能需求。

状态本质就有，就是持有的地方不同，无状态，我理解强调的是服务器端无状态（没完整读过F博士的论文）。URI、http parameters(POST-DATA,query-string)、http header都能放着，无非就是用它们在服务器客户端传来传去，造成无状态的假像。

对于登录用户信息，除了rails2.0用cookie带特殊加工的方式，没见过比session更成熟的方案 - 我孤陋。
ltian上面的方案在安全性上不怎么考究，ajax/javascript就可以达到相同的效果。尽管企业级应用的安全性很多时候是靠非技术因素来保证的，但也需要必要的技术支撑，比如完备的log来追查责任。对于身份验证，log起不到作用。传统BS方式是数据和算法（验证逻辑）都在服务器端，以sessionID的可靠性来保证整个验证体系统的完备及可信。但以ltian的方式，RIA程序放了算法（验证逻辑），Server放了数据（指全部用户数据和其它业务数据），这样就有可能让验证只是走走形式。如果说传统CS模式可以这么做，也有几种假定可以跟RIA作为REST客户端进行对比：
1. 客户端软件反向代码很难 - 验证逻辑不易被恶意用户修改。而RIA程序多建立于虚拟机之上，ajax/javascript更是开放的很。
2. CS程序的通信协议私有性使攻击难度加大 - 建立于HTTP之上REST风格接口，是简单的文本协议，加上对直白的追求。
3. CS程序的整个信息资源分布情况及各资源获取的协议含糊 - REST又追求了直白，而且，一但骗过验证这关，就可以要啥有啥了。

我对CS程序在用户认证上的完备方案也不熟悉，写完上面的东西，也有很多疑问，希望各位释疑。
比如，我上面的分析，都是“用含糊来保证安全”的假定，而这种“安全”根本就不安全。难道CS程序天生就不如BS安全？疑问疑问。

回到服务器端用户认证的问题，个人觉得登录者信息放在session里是天经地义的，按客户端传过来的sessionID到数据库查它完整的session数据，跟按客户端的parameter查数据库取业务数据，没什么两样，当然，session的存储方式各不相同。需要考虑的是，是否向session里放了过度或不恰当的东西？
比如，一个登录者可以管理多个company，当他在列表页点击ID为1的company链接时，进入了详细信息页（常规地址/company/1），但同时把company ID放到session里(！！！)该详细信息页下方有个Edit button，点击就能进入修改页面，注意该页面的URL是/company/edit而不是/company/1/edit，这时仍能正确显示1的已有信息（因为从session里能取到）。从功能上没有任何问题。但显然不太靠谱 - 对比前面列的无状态的好处。
上面场景不靠谱的明显，也有一些含混的情况。比如有些页面需要根据登录者的不同，显示数据不同，或显示内容类型不同，或简单一点显示效果的差异。这时怎么处理更多需要权衡。

27 楼 sofar1218 2008-05-06  

<div class='quote_title'>删除回帖 </div>

26 楼 liusong1111 2008-05-06  

<div class='quote_title'>ltian 写道</div>
<div class='quote_div'>
<div class='quote_title'>liusong1111 写道</div>
<div class='quote_div'>
<div class='quote_title'>ltian 写道</div>
<div class='quote_div'>
<div class='quote_title'>lgx522 写道</div>
<div class='quote_div'>
<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>
<div class='quote_title'>quaff 写道</div>
<div class='quote_div'>
<div class='quote_title'><br/></div>
struts2有restful支持,或者可以自己写ActionMapper来定制. <br/>REST跟SOAP是平等的关系,但是SOAP是一种规范,只能接受标准化的xml和返回标准化的xml,REST是一种风格,没有规定一定要怎么样,REST可以接受任何数据和返回任何数据,即使url一样,也可以智能的根据客户端的不同返回不同的数据,比如是wap浏览器的请求就返回wml,opera之类的返回html,还可以在请求的时候指定返回数据类型,目前的REST只适合做service给其他应用使用,在将来浏览器的功能足够强大了,才有REST的用武之地.</div>
<p> </p>
<p> 我也感觉REST约束最适合的地方是：信息服务，既怎样更好地把信息“给”请求者。而对信息的管理（“改变”），"REST"应该少管。</p>
</div>
<p><br/>这也正是互联网应用与企业应用的一大根本性区别，互联网是以“读”为主的应用，而企业是以为“写”为主的应用。</p>
<p>还不仅仅是“REST”的问题。在企业应用领域尝试折腾了几年的B/S，费了老大力气，软件质量倒是高了（重用、扩展），布署更新问题也解决了，可惜客户还是认为不好用（B/S的交互性总是不如C/S）、性能差（企业应用以写为主，缓存基本无用，sql和存储过程才够快）。有时候看看那帮傻乎乎得意的PBer们，真怀疑B/S是不是不该引入到企业应用来。</p>
</div>
<p>B/S就是发展趋势，如果你看了RIA应用，你会改变看法。<span style='color: #ff0000;'><strong>RIA技术很好解决了楼主的问题</strong></span>和你的担心。RIA 必将成为企业应用开发的主流。</p>
</div>
<p> </p>
<p>RIA直接影响的是客户端技术和体验，间接影响了整个部署和服务器端开发模式，但对解决楼主的问题一点帮助都没有。REST架构和RIA的关系是相辅相成的，而不是替代 - 严格的说，不是一个层面的东西。</p>
</div>
<p>  这里没人认为RIA和REST是一个东西，REST是一种检查规则或者规范，RIA是一种实现。我说的是用RIA可以更加容易地实现REST 的要求</p>
</div>
<p> </p>
<p>楼主关注的是在他提出的场景下，用REST风格去设计服务器端，我只从对外接口的角度粗暴一点说，关注的是如何实现<strong>REST服务提供者</strong>。</p>
<p>而我看到的RIA资料，都测重客户端实现，能跟REST沾上边的，是其作为<strong>REST消费者</strong>的架构风格。</p>
<p>这又是处于两个不同位置、又由同一术语牵连的话题。</p>
<p>你可以从回答楼主最初提出的四个问题开始，来讲讲RIA在服务器端是怎么解决这些问题的，我没有RIA实践经验。</p>

25 楼 leebai 2008-05-06  

<div class='quote_title'>liusong1111 写道</div>
<div class='quote_div'>
<div class='quote_title'>robbin 写道</div>
<div class='quote_div'>
<div class='quote_title'>引用</div>
<div class='quote_div'>Rails “其实不是4个动词，而是4类动词”，这个能接受一点，还是有点晕： 把动词分成4类，在架构上有什么特别意义？</div>
<br/><br/>REST叫做“带表象的状态迁移”，动词的分类是因为这4类操作会对资源的状态带来不同的影响，造成状态的迁移。 <br/><br/>GET 不影响资源的状态 <br/>POST 创建一个新的资源 <br/>PUT 修改一个资源的状态 <br/>DELETE 删除一个资源 <br/><br/>所以这4类操作给资源状态迁移带来的结果是不一样的。 <br/><br/><br/><br/></div>
<br/><br/>划分依据一： 动作是作用在整个类型（集合，复数）之上，还是针对一个具体资源（单数）。 <br/>划分依据二： 会不会改变资源状态，把GET和剩下三个区分出来。 <br/>划分依据三： 更改资源状态的POST(create)，重复提交多次会造成问题，而PUT(update)、DELETE(destroy)就不会 －－ 称为幂等性－－ 据此可以进行安全的失败重试。 <br/><br/>在代码组织上（及相应的URL上），传统的mvc的controller，更像是一批操作的集合（容器，分组），而REST风格的controller，本身代表一个Resource（一个名词），它具有容器的概念而且更具体，最具重要意义的是，给出了一个依据，用于将传统意义的操作集合进行进一步更细粒度的拆分，且不但不破坏其含义，反而使其意义更明确。我们做应用系统的，经常发愁的不是东西有多大，而是能不能拆分、好不好拆分，REST风格的这个依据具有全局意义，使得代码组织、维护上有了加强，实现代码更容易定位，命名上更一致。 <br/><br/>四类操作，而不仅限于四个动作，比如将一东西另存为的操作，就属于POST（create方法）这类，可以起名为save_as，这样，就给细节设计提供了依据，同时让命名更一致。再比如激活操作，就属于UPDATE(update方法)的变种，命名还是遵循其原意activate，UPDATE的变种还可能是更新部份信息，比如只更新一个东西的状态，就叫update_status；设置一个东西为primary，可以起名为set_primary，也是UPDATE的范畴。 <br/>POST（create方法）的变种可能有quick_create等。 <br/>GET可以有index的变种（list_xxx,search_xxx,find_xxx等），当然还包括new、edit、show的变种，比如preview。 <br/><br/>再如，一个对关联C的操作，传统方式可以在AController里定义create_c_from_b，也可以在BController里定义create_c_from_a，实现者可能随手在两者之一中实现。这样不但给维护中代码定位带来难度，而且更重要的是，在后续开发中，很难避免在不同的controller中，出现名字类似的action，实现的却是同一个功能。这种重复代码的发现和消除成本会越来越高，尤其是随着后续的功能变更，最终的方案还是回到将controller作为资源的老路上来。 <br/>我们目前使用上，并没有完全把关联的东西都作为resource，只是尽量遵循不让其产生二义性的原则。 <br/><br/>-- <br/>以上基于rails的实现 <br/>-- <br/>。。。 <br/><br/></div>
<p><br/><br/>liusong1111的“三个划分依据”不错，后面的“四类动作”论述也很精彩。 <br/><br/>我也说说自己的看法： <br/><br/>HTTP/REST只说过有PUT、DELETE有幂等性，多次提交是安全的；<span style='color: #ff0000;'>并没有说过POST没有幂等性</span>。 <br/><br/>HTTP将PUT定位为“Create, Update”，和DELETE一样，<span style='color: #ff0000;'>其URI资源指向某个实际资源</span>，这一点是PUT、DELETE有幂等性的唯一原因；而将POST定位为“什么都可以干”，其URI指向的资源一个“<span style='color: #ff0000;'>万能处理器</span>”，<span style='color: #ff0000;'>而非实际资源</span>，正也因为URI指向非实际资源，所以也就无所谓幂等还是非幂等，因为其行为及幂等性完全取决于后台具体实现。 <br/><br/>由于现实应用中Create很少在客户端指定实际资源ID（主键大多都是后台产生），因此PUT方法（URI必须指定实际资源ID）的Create功能不便使用，才<span style='color: #ff0000;'>借助</span>万能的POST来充当Create功能。也就是说，<span style='color: #ff0000;'>POST并非先天就是只能用于Create，先天就是非幂等</span>。 <br/><br/>各种“RESTful” 在POST/PUT/DELETE的使用上，其实并不吻合HTTP/REST的本来意愿，也并不优雅，有点暴力，个人感觉是这类“RESTful”有<span style='color: #ff0000;'>异化</span>REST的嫌疑。 <br/><br/>我相信将动作分为四类有一定的合理性，但我觉得划分为两类（也就是你说的第二个层次）也不错:<span style='color: #ff0000;'><span style='color: #000000;'>一种是</span>GET负责读操作</span>，总是安全的；<span style='color: #ff0000;'><span style='color: #000000;'>另一种是</span>POST负责写操作</span>，不安全的。这种分法也完全符合HTTP/REST，而且只用到HTTP 1.0的功能，按照某位大师的说法，<span style='color: #ff0000;'>约束于越老的HTTP版本，越是RESTful</span>。</p>
<p> </p>

24 楼 lgx522 2008-05-06  

<div class='quote_title'>ltian 写道</div>
<div class='quote_div'>
<div class='quote_title'>lgx522 写道</div>
<div class='quote_div'>
<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>
<div class='quote_title'>quaff 写道</div>
<div class='quote_div'>
<div class='quote_title'><br/></div>
struts2有restful支持,或者可以自己写ActionMapper来定制. <br/>REST跟SOAP是平等的关系,但是SOAP是一种规范,只能接受标准化的xml和返回标准化的xml,REST是一种风格,没有规定一定要怎么样,REST可以接受任何数据和返回任何数据,即使url一样,也可以智能的根据客户端的不同返回不同的数据,比如是wap浏览器的请求就返回wml,opera之类的返回html,还可以在请求的时候指定返回数据类型,目前的REST只适合做service给其他应用使用,在将来浏览器的功能足够强大了,才有REST的用武之地.</div>
<p> </p>
<p> 我也感觉REST约束最适合的地方是：信息服务，既怎样更好地把信息“给”请求者。而对信息的管理（“改变”），"REST"应该少管。</p>
</div>
<p><br/>这也正是互联网应用与企业应用的一大根本性区别，互联网是以“读”为主的应用，而企业是以为“写”为主的应用。</p>
<p>还不仅仅是“REST”的问题。在企业应用领域尝试折腾了几年的B/S，费了老大力气，软件质量倒是高了（重用、扩展），布署更新问题也解决了，可惜客户还是认为不好用（B/S的交互性总是不如C/S）、性能差（企业应用以写为主，缓存基本无用，sql和存储过程才够快）。有时候看看那帮傻乎乎得意的PBer们，真怀疑B/S是不是不该引入到企业应用来。</p>
</div>
<p>B/S就是发展趋势，如果你看了RIA应用，你会改变看法。RIA技术很好解决了楼主的问题和你的担心。RIA 必将成为企业应用开发的主流。</p>
</div>
<p>不只是看，还在用。</p>
<p>RIA相对于C/S，最大的好处有二：一是可以单界面更新，不必像C/S要全程序重启更新；二是方便集成，可以扔到异构程序的界面里。</p>
<p>可惜RIA当前还是不如C/S好做啊，做一个像样的RIA界面，C/S都做出三四个来了；找一个合格的RIA程序员费的事，可以找出十个C/S程序员了。</p>
<p>还有一点最致命的，RIA在企业应用里跑起来比C/S慢多了（不论是客户端还是服务器端）。</p>
<p>事实最终会证明，“外部应用B/S，内部应用C/S”这句老俗话。</p>