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版:-)。

评论

23 楼 liusong1111 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应用，你会改变看法。<span style='color: #ff0000;'><strong>RIA技术很好解决了楼主的问题</strong></span>和你的担心。RIA 必将成为企业应用开发的主流。</p>
</div>
<p> </p>
<p>RIA直接影响的是客户端技术和体验，间接影响了整个部署和服务器端开发模式，但对解决楼主的问题一点帮助都没有。REST架构和RIA的关系是相辅相成的，而不是替代 - 严格的说，不是一个层面的东西。</p>

22 楼 lgx522 2008-05-06  

<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>

21 楼 quaff 2008-05-06  

<div class='quote_title'>leebai 写道</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>
<p><br/><br/>Transfer是不是翻成“<span style='color: #ff0000;'>传递、传输</span>”更好点？ <br/><br/>我仔细检查了Fielding论文<span style='color: #ff0000;'>第5章</span>对REST的描述，发现作者所描述的<span style='color: #ff0000;'>信息流动都是单向</span>的，既，"<span style='color: #ff0000;'>表象状态RES</span>"总是从服务端到客户端（中间可经过多层），也就是<span style='color: #ff0000;'>GET</span>经历的过程；该章内容并不涉及“<span style='color: #ff0000;'>state</span>”本身在服务器上的“<span style='color: #ff0000;'>变更</span>（或迁移，Transfer的另一个意思）”。</p>
<p> </p>
<p><span style='font-size: medium;'> 补充：又看了一遍原文，基本确定dlee对“REST”的“T”的翻译是有问题的，Transfer就是指“状态”（或称信息、数据、资源 。。。Hypertext*）的“<span style='color: #ff0000;'>传输</span>”，和HTTP的第三个T是一样的内涵，The Hypertext Transfer Protocol (HTTP)译为“超文本<span style='color: #ff0000;'>传输</span>协议”，Representational State Transfer (REST)没有理由译成“表述性状态<span style='color: #ff0000;'>转移</span>”。这么翻译有可能导致人们对REST的误解，以为REST描述的是“<span style='color: #ff0000;'>状态变更</span>”问题。</span></p>
</div>
<p>同意你的说法</p>

20 楼 liusong1111 2008-05-06  

robbin 写道

引用

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

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

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

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

划分依据一： 动作是作用在整个类型（集合，复数）之上，还是针对一个具体资源（单数）。
划分依据二： 会不会改变资源状态，把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的认识程度和实现上的约束。

19 楼 leebai 2008-05-06  

<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>
<p><br/><br/>Transfer是不是翻成“<span style='color: #ff0000;'>传递、传输</span>”更好点？ <br/><br/>我仔细检查了Fielding论文<span style='color: #ff0000;'>第5章</span>对REST的描述，发现作者所描述的<span style='color: #ff0000;'>信息流动都是单向</span>的，既，"<span style='color: #ff0000;'>表象状态RES</span>"总是从服务端到客户端（中间可经过多层），也就是<span style='color: #ff0000;'>GET</span>经历的过程；该章内容并不涉及“<span style='color: #ff0000;'>state</span>”本身在服务器上的“<span style='color: #ff0000;'>变更</span>（或迁移，Transfer的另一个意思）”。</p>
<p> </p>
<p><span style='font-size: medium;'> <span style='font-size: small;'>补充：又看了一遍原文，基本确定dlee对“REST”的“T”的翻译是有问题的，Transfer就是指“状态”（或称信息、数据、资源 。。。Hypertext*）的“<span style='color: #ff0000;'>传输</span>”，和HTTP的第三个T是一样的内涵，The Hypertext Transfer Protocol (HTTP)译为“超文本<span style='color: #ff0000;'>传输</span>协议”，Representational State Transfer (REST)没有理由译成“表述性状态<span style='color: #ff0000;'>转移</span>”。这么翻译有可能导致人们对REST的误解，以为REST描述的是“<span style='color: #ff0000;'>状态变更</span>”问题。</span></span></p>
<p> </p>
<p><span style='font-size: small;'>继续补充：刚发现dlee在译文中（6.5.3小节），居然认为HTTP的传统翻译“超文本<span style='color: #ff0000;'>传输</span>协议”不对。真是太荒谬了。看来经验再丰富的老手，也有糊涂的时候。</span></p>

18 楼 leebai 2008-05-06  

<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>

17 楼 leebai 2008-05-06  

rain2005 写道

引用

但对于RESTful POST/PUT/DELETE，数据库数据的情况要比简单资源(单一文件)要复杂

不管是POST/PUT/DELETE还是什么操作，只要你定义一个url能够唯一标识你将要操作的数据，后台随便你做多少操作都没有什么关系。

这种对REST“宽泛的约束”的解读，我能接受。

16 楼 leebai 2008-05-06  

<div class='quote_title'>robbin 写道</div>
<div class='quote_div'><br/>HTTP Basic验证也无非就是HTTP Header里面夹带了私货，这和Cookie是一样的，Cookie也是在HTTP Header里面的，这两者没有任何区别。</div>
<div class='quote_div'>另外Rails的REST实现当中，就是支持使用HTTP Basic验证的，你可以看看ActiveResource，实现起来特别简单。 <br/></div>
<p>刚才正在看rfc2617、2616。。。HTTP 验证和Cookie对user agent 来说虽然都视头标，但实际还是有差别的：<span style='color: #ff0000;'>HTTP Proxy</span>是不不理会Cookie的，但对Authorization头标却要做判断；另外session cookie是<span style='color: #ff0000;'>服务器颁发</span>的，而Authorization头标一开始就<span style='color: #ff0000;'>来自浏览器本身</span>，具体还在看中。。。。ActiveResource,哪天也看看。</p>
<p> </p>

15 楼 robbin 2008-05-06  

引用

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

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

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

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

14 楼 leebai 2008-05-06  

<div class='quote_title'>robbin 写道</div>
<div class='quote_div'>老实说我也没有仔细研究过Fielding的论文，我对于REST的认识来自于Rails框架的REST功能。所以就Rails的REST来说： <br/><br/><br/>反正Rails的REST是可以携带Cookie的。 <br/><br/><br/>对于Rails的REST来说，proxy cache并不是其主要目的，即便不REST，一样可以cache，有了REST，cache也没啥区别。 <br/><br/><br/>就Rails的REST来说吧，其实不是<strong><span style='color: #ff0000;'>4个</span></strong>动词，而是<strong><span style='color: #ff0000;'>4类</span></strong>动词，你可以用GET来定义很多动词，也可以用POST/PUT/DELETE定义很多动词。这些动词的定义都是通过routes.rb来实现的，动词的属性只有这四类，但是你可以用这四类属性定义n多的动词出来。 <br/><br/>
<div class='quote_title'>引用</div>
<div class='quote_div'><br/>另外还有几个主题之外的RESTful疑问，一并请教： <br/>a、现在很多论坛有一个功能：必须回复才能看到主帖，但看到和看不到时的访问URI是相同的，这种设计是否违背REST？ <br/>b、基本上论坛帖子都有访问次数统计，其实就是GET操作的时候改变了服务器State，应该也是违背REST吧？ <br/>c、只使用POST/GET是否也能实现RESTful？我看Fielding的论文中并没有提到必须使用PUT/DELETE。 <br/>d、在《RESTful Web Services》的序言中，作者写道： <br/>作者的意思是不是：POST/PUT/DELETE等其实都不是RESTful的本质，只有 GET+URI 才是RESTful的核心战斗力？</div>
<br/><br/>a、起码不违背Rails的REST <br/>b、这个肯定不违背，统计次数不是帖子的状态 <br/>c、Rails就是用POST模拟PUT和DELETE的，所以是肯定的 <br/>d、他应该指的是HTTP/1.1协议支持的那些复杂的功能，让Web变得复杂了 <br/></div>
<p> </p>
<p>既然Rails也用Cookie，那Cookie最多只是违背RESTmax:-)，不违背RESTful，俺们可以放心使用了。</p>
<p> <br/>我也觉得目前proxy cache意义不大了，现在共享上网基本上都是通过gate，proxy 很少用。对于2，我的主要意思是，企业应用的请求reqsponse,,应该都是Cache-Control：No-cache的，服务器自己的cache是另一回事。</p>
<p>Rails “其实不是<strong><span style='color: #ff0000;'>4个</span></strong>动词，而是<strong><span style='color: #ff0000;'>4类</span></strong>动词”，这个能接受一点，还是有点晕： 把动词分成4类，在架构上有什么特别意义？</p>
<p><span style='color: #ff0000;'>看来a/b是否违背rest..有争议</span>。</p>
<p>谢谢站长的回复，顺便提个意见：这个发帖编辑器功能很强大，但是在<a href='../537093/' id='editor_tab_bbcode'><span style='color: #000000;'>BBCode编辑器</span></a> 和 <a href='../537093/' class='activetab' id='editor_tab_rich'><span style='color: #000000;'>可视化编辑器</span></a> 之间来回切换时，有时格式会乱，比如：可视编辑中修改了“引用区”之后再进BBcode，再回来就乱了。</p>
<p> </p>

13 楼 quaff 2008-05-06  

leebai 写道

rain2005 写道

1.肯定要违背REST服务器Stateless 原则
   可以考虑SNA架构，服务器端实现无状态不是很难，JE里面有很多讨论
2.确实是如你所言
3.这类应用面对的“数据对象”和REST中的“Resource”应该是不同的
   不用死扣概念，按照我的理解，只要需要展现的数据可以使用XML来描述（或者其它的格式，但是XML更加通用），数据库里面的所有数据都可以表现成XML把？
4.只使用POST/GET可以实现RESTful，rails就是借助method="delete/put"参数来模拟实现的
5.REST只是一种HTTP协议下实现远程数据交换的概念，具体实现就多种多样了，在一般都应用里面最好是选择性的使用REST，在说了在java里面也没有rails那样完美的实现方案！
以上只是我个人的理解，请大家喷一喷有什么不对的地方！

3、我想说的是，对于 RESTful GET ，确实如你所说，什么数据都可以，因为对GET来说返回的数据都是一个整体；但对于RESTful POST/PUT/DELETE，数据库数据的情况要比简单资源(单一文件)要复杂。

5、“选择性的使用REST”，，，很赞同你这句话。

不了解rails，所以不理解“在java里面也没有rails那样完美的实现方案”？是做不到，还是没人做？

struts2有restful支持,或者可以自己写ActionMapper来定制.
REST跟SOAP是平等的关系,但是SOAP是一种规范,只能接受标准化的xml和返回标准化的xml,REST是一种风格,没有规定一定要怎么样,REST可以接受任何数据和返回任何数据,即使url一样,也可以智能的根据客户端的不同返回不同的数据,比如是wap浏览器的请求就返回wml,opera之类的返回html,还可以在请求的时候指定返回数据类型,目前的REST只适合做service给其他应用使用,在将来浏览器的功能足够强大了,才有REST的用武之地.

12 楼 rain2005 2008-05-06  

引用

但对于RESTful POST/PUT/DELETE，数据库数据的情况要比简单资源(单一文件)要复杂

不管是POST/PUT/DELETE还是什么操作，只要你定义一个url能够唯一标识你将要操作的数据，后台随便你做多少操作都没有什么关系。

11 楼 robbin 2008-05-06  

<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>
<p>&lt;p&gt;</p>
<div class='quote_title'>quaff 写道</div>
<div class='quote_div'>我的看法: 1.在http header里面带上授权信息,一般web service也是在soap头里面加,还有GData api好像也是这样的 2.Cacheable针对的是那些公开的资源. 3.扩充动词是必要的 4. 原来面对的问题在REST中一样会面对 a.应该违反了REST b.也违反 c.没有规定一定要用什么方法,REST是一种style,不是specification d.大部分情况下都是用GET去模拟其他动作的,因为浏览器的限制,比如连接只能是GET. </div>
<p>这么说，企业应用程序要保持RESTful的纯洁性是很难的了。。。 </p>
<p>对于回复1，几年前做7wxAop(on IBM Websphere) 与 domino 集成的SSO时，用过HTTP的Basic验证机制，有点忘了。。。刚才翻了一下7wxAop后端代码：</p>
<pre name='code' class='java'> /*外置用户认证时取用户信息,IBM WebSphere单点登陆、SAP WAS单点登陆 */
String ssoType = DeepConfig.ssoType;
String curUserId = getUserID(req);
if(ssoType != null &amp;&amp; ssoType.length()&gt;0 &amp;&amp; curUserId==null){//当前用户未本地登陆且配置为单点登陆时
String userID = null;
if("IBM".equalsIgnoreCase(ssoType)){//Get IBM SSO UID
if("Basic".equals(req.getAuthType()))
userID = req.getRemoteUser();

}else if("SAP".equalsIgnoreCase(ssoType)){//Get SAP SSO UID

...</pre>
<p>HTTP的验证机制某种程度上确实可以代替基于cookies的会话，看来需要再仔细看看HTTP spec 和相关的 rfc2617。谢谢你的提醒。</p>
<p> </p>
</div>
<p>HTTP Basic验证也无非就是HTTP Header里面夹带了私货，这和Cookie是一样的，Cookie也是在HTTP Header里面的，这两者没有任何区别。</p>
<p>另外Rails的REST实现当中，就是支持使用HTTP Basic验证的，你可以看看ActiveResource，实现起来特别简单。</p>

10 楼 quaff 2008-05-06  

<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>
<p>&lt;p&gt;</p>
<div class='quote_title'>quaff 写道</div>
<div class='quote_div'>我的看法: 1.在http header里面带上授权信息,一般web service也是在soap头里面加,还有GData api好像也是这样的 2.Cacheable针对的是那些公开的资源. 3.扩充动词是必要的 4. 原来面对的问题在REST中一样会面对 a.应该违反了REST b.也违反 c.没有规定一定要用什么方法,REST是一种style,不是specification d.大部分情况下都是用GET去模拟其他动作的,因为浏览器的限制,比如连接只能是GET. </div>
<p>这么说，企业应用程序要保持RESTful的纯洁性是很难的了。。。 </p>
<p>对于回复1，几年前做7wxAop(on IBM Websphere) 与 domino 集成的SSO时，用过HTTP的Basic验证机制，有点忘了。。。刚才翻了一下7wxAop后端代码：</p>
<pre name='code' class='java'> /*外置用户认证时取用户信息,IBM WebSphere单点登陆、SAP WAS单点登陆 */ String ssoType = DeepConfig.ssoType; String curUserId = getUserID(req); if(ssoType != null &amp;&amp; ssoType.length()&gt;0 &amp;&amp; curUserId==null){//当前用户未本地登陆且配置为单点登陆时 String userID = null; if("IBM".equalsIgnoreCase(ssoType)){//Get IBM SSO UID if("Basic".equals(req.getAuthType())) userID = req.getRemoteUser();  }else if("SAP".equalsIgnoreCase(ssoType)){//Get SAP SSO UID  ...</pre>
<p>HTTP的验证机制某种程度上确实可以代替基于cookies的会话，看来需要再仔细看看HTTP spec 和相关的 rfc2617。谢谢你的提醒。</p>
<p> </p>
</div>
<p>其实我说的不是Http的Basic验证,我的意思是在http header里面带上用户名密码或者token</p>

9 楼 leebai 2008-05-06  

rain2005 写道

1.肯定要违背REST服务器Stateless 原则
   可以考虑SNA架构，服务器端实现无状态不是很难，JE里面有很多讨论
2.确实是如你所言
3.这类应用面对的“数据对象”和REST中的“Resource”应该是不同的
   不用死扣概念，按照我的理解，只要需要展现的数据可以使用XML来描述（或者其它的格式，但是XML更加通用），数据库里面的所有数据都可以表现成XML把？
4.只使用POST/GET可以实现RESTful，rails就是借助method="delete/put"参数来模拟实现的
5.REST只是一种HTTP协议下实现远程数据交换的概念，具体实现就多种多样了，在一般都应用里面最好是选择性的使用REST，在说了在java里面也没有rails那样完美的实现方案！
以上只是我个人的理解，请大家喷一喷有什么不对的地方！

3、我想说的是，对于 RESTful GET ，确实如你所说，什么数据都可以，因为对GET来说返回的数据都是一个整体；但对于RESTful POST/PUT/DELETE，数据库数据的情况要比简单资源(单一文件)要复杂。

5、“选择性的使用REST”，，，很赞同你这句话。

不了解rails，所以不理解“在java里面也没有rails那样完美的实现方案”？是做不到，还是没人做？

8 楼 robbin 2008-05-06  

老实说我也没有仔细研究过Fielding的论文，我对于REST的认识来自于Rails框架的REST功能。所以就Rails的REST来说：

引用

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

反正Rails的REST是可以携带Cookie的。

引用

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

对于Rails的REST来说，proxy cache并不是其主要目的，即便不REST，一样可以cache，有了REST，cache也没啥区别。

引用

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

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

就Rails的REST来说吧，其实不是4个动词，而是4类动词，你可以用GET来定义很多动词，也可以用POST/PUT/DELETE定义很多动词。这些动词的定义都是通过routes.rb来实现的，动词的属性只有这四类，但是你可以用这四类属性定义n多的动词出来。

引用

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

a、起码不违背Rails的REST
b、这个肯定不违背，统计次数不是帖子的状态
c、Rails就是用POST模拟PUT和DELETE的，所以是肯定的
d、他应该指的是HTTP/1.1协议支持的那些复杂的功能，让Web变得复杂了

7 楼 leebai 2008-05-06  

<p>&lt;p&gt;</p>
<div class='quote_title'>quaff 写道</div>
<div class='quote_div'>我的看法: 1.在http header里面带上授权信息,一般web service也是在soap头里面加,还有GData api好像也是这样的 2.Cacheable针对的是那些公开的资源. 3.扩充动词是必要的 4. 原来面对的问题在REST中一样会面对 a.应该违反了REST b.也违反 c.没有规定一定要用什么方法,REST是一种style,不是specification d.大部分情况下都是用GET去模拟其他动作的,因为浏览器的限制,比如连接只能是GET. </div>
<p>这么说，企业应用程序要保持RESTful的纯洁性是很难的了。。。 </p>
<p>对于回复1，几年前做7wxAop(on IBM Websphere) 与 domino 集成的SSO时，用过HTTP的Basic验证机制，有点忘了。。。刚才翻了一下7wxAop后端代码：</p>
<pre name='code' class='java'> /*外置用户认证时取用户信息,IBM WebSphere单点登陆、SAP WAS单点登陆 */
String ssoType = DeepConfig.ssoType;
String curUserId = getUserID(req);
if(ssoType != null &amp;&amp; ssoType.length()&gt;0 &amp;&amp; curUserId==null){//当前用户未本地登陆且配置为单点登陆时
String userID = null;
if("IBM".equalsIgnoreCase(ssoType)){//Get IBM SSO UID
if("Basic".equals(req.getAuthType()))
userID = req.getRemoteUser();

}else if("SAP".equalsIgnoreCase(ssoType)){//Get SAP SSO UID

...</pre>
<p>HTTP的验证机制某种程度上确实可以代替基于cookies的会话，看来需要再仔细看看HTTP spec 和相关的 rfc2617。谢谢你的提醒。</p>
<p> </p>

6 楼 rain2005 2008-05-06  

1.肯定要违背REST服务器Stateless 原则
   可以考虑SNA架构，服务器端实现无状态不是很难，JE里面有很多讨论
2.确实是如你所言
3.这类应用面对的“数据对象”和REST中的“Resource”应该是不同的
   不用死扣概念，按照我的理解，只要需要展现的数据可以使用XML来描述（或者其它的格式，但是XML更加通用），数据库里面的所有数据都可以表现成XML把？
4.只使用POST/GET可以实现RESTful，rails就是借助method="delete/put"参数来模拟实现的
5.REST只是一种HTTP协议下实现远程数据交换的概念，具体实现就多种多样了，在一般都应用里面最好是选择性的使用REST，在说了在java里面也没有rails那样完美的实现方案！
以上只是我个人的理解，请大家喷一喷有什么不对的地方！

5 楼 leebai 2008-05-06  

rain2005 写道

引用

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

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

谢谢推荐，我在je上也搜过rest。这些问题是看过很多rest资料后还存在的，所以希望有具体回答。

4 楼 quaff 2008-05-06  

<p>我的看法:</p>
<p>1.在http header里面带上授权信息,一般web service也是在soap头里面加,还有GData api好像也是这样的</p>
<p>2.Cacheable针对的是那些公开的资源.</p>
<p>3.扩充动词是必要的</p>
<p>4. 原来面对的问题在REST中一样会面对</p>
<p> </p>
<p>a.应该违反了REST</p>
<p>b.也违反</p>
<p>c.没有规定一定要用什么方法,REST是一种style,不是specification</p>
<p>d.大部分情况下都是用GET去模拟其他动作的,因为浏览器的限制,比如连接只能是GET.</p>