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

评论

63 楼 leebai 2008-05-08  

<div class='quote_title'>dlee 写道</div>
<div class='quote_div'>。。。<br/>
<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>再给你举点例证，如果你还糊涂，我可要对你智商进行攻击了:-)： </div>
<br/>瞧瞧，故态复萌了不是。我前面说什么来着。</div>
<p> </p>
<p>其他正文不细看，找这个倒挺眼贼。。。。 <img src='../../../../../../images/smiles/icon_eek.gif' alt=''/>G.M.D.F.D.P<img src='../../../../../../images/smiles/icon_eek.gif' alt=''/>  猜猜什么意思<img src='../../../../../../images/smiles/icon_biggrin.gif' alt=''/></p>

62 楼 clia 2008-05-08  

<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>你的“表形性状态”我基本赞同，还有“最后一片乌云”是：<br/><br/>Representational 除了表示“形”，是不是还表示Header！、Method、URI、reponse code 等“型”的信息？</div>
<p><br/>又翻了一下论文，为追求真义，还下了英文原文来看了一下，发现论文中最难翻的就是这个“representation”了。<br/>如果“representational”可以翻成“表形性”的话，那“representation”又该如何翻？<br/>资源的：“形象”？“外形”？“表现形式”？“表形”？“表示”？</p>
<div class='quote_title'>Fielding 写道</div>
<div class='quote_div'>5.2.1.2 Representations<br/>REST components perform actions on a resource by using a representation to capture the<br/>current or intended state of that resource and transferring that representation between<br/>components.</div>
<p><br/>从“transferring that representation”来看，还是翻成“表示”更合适，但“表示性状态”又会使人犯迷糊，真是难两全啊！<br/><br/>之前想不明白，除了HTML、JPEG等以外，XML、JSON这些不具“形”的东西（不是给人看，而是给机器处理），会不会算是作者所指的“representation”呢？可能是我理解错了，作者所指的representation并没有说一定要具“形”，被之前的“表示层”这样的概念误导了，以为“representational”都是要给人看的。<br/><br/>leebai的问题，Header！、Method、URI、reponse code 等应该是属于REST里的其他数据元素，如下表：<br/><br/>                        Table 5-1. REST Data Elements<br/>            Data Element                                      Modern Web Examples<br/>resource                                             the intended conceptual target of a hypertext reference<br/>resource                   identifier              URL, URN<br/>representation                              HTML document, JPEG image<br/>representation metadata       media type, last-modified time<br/>resource metadata                      source link, alternates, vary<br/>control data                                    if-modified-since, cache-control<br/></p>
<div class='quote_title'>dlee 写道</div>
<div class='quote_div'>那么，所谓“透明的传输”从何而来？</div>
<p><br/>“透明的传输”好像是我说的，我是为了说明应用层协议应该使用传输层已经提供好的“透明的传输”。REST是应用层的架构风格，而在这种架构里已经包含了origin server、gateway、proxy、user agent这四种components，在架构内部足以实现缓存和安全，在它们之间的数据传输还是应该使用传输层的透明传输，所以这么说也没有错吧？</p>
<p> </p>

61 楼 dlee 2008-05-08  

leebai 写道

所以，transport 与 transfer用于表示“传输”概念时，只有及物与不及物的词法差别，没有你认为的词义差别：如果主体是something,就用transfer，主体非名词如how或有宾语，就用transport 。应用层连英文transport都可以用，中文忌讳用“传输”就更荒唐了，Fielding一句有岐义的“ HTTP is not a Transport Protocol”，何必当圣旨用呢。

“transfer”翻译为“转移”有很大问题吗？还是你自己的习惯问题吧。将数据从一个地方“转移”到另一个地方，说不通吗？
按照我对HTTP的理解，这个“转移”的过程对于应用软件来说并不是完全透明的传输，还涉及到中间组件的一些处理，包括缓存、安全审计等工作。中间组件要有效地做缓存和安全审计等工作，就必须要理解操作的语义，这就是Fielding所说的：

Fielding 写道

应用软件代表的是一个系统的“理解业务”（business-aware）的那部分功能

HTTP是一个应用层的协议，REST也是一个应用软件级别的架构风格。
我给你举个例子说明为何这个“转移”的过程并不是完全透明的传输。

假设HTTP客户端希望确保此次请求获得的数据来自于来源服务器，而不是通信链中间的某个缓存，它需要自己在请求的HTTP包头中加入控制信息。
假设HTTP服务器希望HTTP通信链中的缓存不要对当前数据做缓存，它也需要自己在响应的HTTP包头中加入控制信息。

这两个例子都不是透明的，应用软件还需要意识到通信链中间的缓存的存在，而不能简单地将缓存看作是阳光空气一样透明的东西。那么，所谓“透明的传输”从何而来？

而“传输”的过程对于应用软件来说，是一个完全透明的比特搬运过程。路由器的智能仅限于确定路由和寻址，它完全不能理解数据包的操作语义，也就是完全不需要理解业务。我以前做过一点网络协议开发，一提到“传输协议”，我就想到那些差错控制、重传、滑动窗口之类的东西。

“transport”和“transfer”这两个词我不同意你说的唯一区别仅仅在于及物和非及物。它们的内涵丰富的程度不同，在语义上也存在差别。你的说法过于简单化了。

leebai 写道

再给你举点例证，如果你还糊涂，我可要对你智商进行攻击了:-)：

瞧瞧，故态复萌了不是。我前面说什么来着。

60 楼 leebai 2008-05-08  

<div class='quote_title'>dlee 写道</div>
<div class='quote_div'>
<div class='quote_title'>clia 写道</div>
<div class='quote_div'>比如星际里面把一个人从一个星球传送到令一个星球，我们只看见两端的传送门，而看不见人是怎样被传送过去的，因此这个传输过程对我们是透明的，这正好适用于应用层的协议。</div>
<br/>以这个观点来理解HTTP和REST是错误的。REST强调通过使用统一接口来实现操作语义对于中间组件的可见性，其目的并不是为了实现<strong>透明的传输</strong>。REST其实更强调中间组件的作用，而不是强调通信链两端组件的作用。与实现数据包的透明传输有关的工作TCP已经解决的非常好了，根本就不需要HTTP来解决。两位同学为何对“传输”一词如此执著？我很不解。不过只是一个动词，能否跳开“传输”这个词来思考问题。其实“传输”所直接对应的“transport”在技术论文中有很明确的含义，Fielding是不会随便乱用的。 <br/><br/>leebai说应该将“传输协议”改为“传输层协议”，我觉得价值不是很大。至少我们以前在翻译这篇论文时，大家共同的理解“传输协议”就是“传输层协议”。现在按照你这样一改，既有“传输层协议”，还有很多应用层的“传输协议”，读者的脑袋不会爆掉才怪！ <br/><br/>“transfer”在中文中并没有完全精确的动词与之相对应，这一点我同意。“转移”仍然不是非常准确，但是翻译为“传输”就更不靠谱了。 <br/><br/>思而不学则殆，同学！</div>
<p> </p>
<p>你说我思而不学，我说你学而不思，多没意思啊<img src='../../../../../../images/smiles/icon_wink.gif' alt=''/>?</p>
<p> dlee同学，你最大的问题是：谈论问题时容易脱离问题本身，而对讨论者的个人能力、特质、习性妄下定义。面对面的交流也未必能真正了解一个人，更何况网络社区的交互信息交互能力是很有限的，你以为自己有超感知能力？</p>
<p> </p>
<p>回归本题。其实这个HTTP/REST意涵问题、transfer问题，<span style='color: #ff0000;'>我们现在基本搞清楚了，就你还在糊涂</span>。</p>
<p>再给你举点例证，如果你还糊涂，我可要对你智商进行攻击了:-)： </p>
<p> </p>
<p><span style='color: #ff0000;'>应用层协议</span>中，有一个RTP(<span style='font-size: x-small;'>实时传输协议，用于音视频系统</span>)，其英文正式名称就是： <span style='color: #ff0000;'>Real-time<strong><span style='font-size: medium;'> Transport</span></strong> Protocol</span> 。</p>
<p>RFC2616里也有这样的说法：。。。since  HTTP <span style='font-size: medium; color: #ff0000;'>transports</span> all message-bodies as payload 。。。(19.4.7)</p>
<p> </p>
<p> </p>
<p>所以，<span style='color: #000000;'>transport</span> 与 <span style='color: #000000;'>transfer</span>用于表示“传输”概念时，<span style='color: #ff0000;'>只有及物与不及物的词法差别，没有你认为的词义差别</span>：如果主体是something,就用transfer，主体非名词如how或有宾语，就用transport 。应用层连英文<span style='color: #ff0000;'>transport</span>都可以用，中文忌讳用“<span style='color: #ff0000;'>传输</span>”就更荒唐了，Fielding一句有岐义的“ HTTP is not a Transport Protocol”，何必当圣旨用呢。</p>
<p> </p>
<p> </p>
<p>你以后的翻译作品如果坚持应用层使用“转移”代替“传输”，小心书卖不出去，即使有人买了也不容易读懂。</p>
<p>赶紧把你的REST译文中的“转移”全换成“传输”，“HTTP不是一种传输协议”改成"HTTP不是一种传输层协议"，<span style='color: #ff0000;'>让更多的人能够从中受益</span>。</p>
<p> </p>
<p>我已经把你的译文打印成小册子了(版权？)，这个文章确实不错。以前还真没看过博士论文，认识软件系统的最高层次只到Specification级别，看来更高的纯理论层次才是技术的顶峰（或最低的基础）。你的评价“思而不学”，对，也不对，我不学的只是哪些末流东西，核心的东西还是稀饭的。</p>
<p> </p>

59 楼 clia 2008-05-08  

dlee 写道

leebai说应该将“传输协议”改为“传输层协议”，我觉得价值不是很大。至少我们以前在翻译这篇论文时，大家共同的理解“传输协议”就是“传输层协议”。现在按照你这样一改，既有“传输层协议”，还有很多应用层的“传输协议”，读者的脑袋不会爆掉才怪！

“transfer”在中文中并没有完全精确的动词与之相对应，这一点我同意。“转移”仍然不是非常准确，但是翻译为“传输”就更不靠谱了。

所以我才提议把应用层的叫做“传送”，传输层的继续叫“传输”啊。
按我现在的中文水平来理解，我觉得“传输”和“传送”还是有点不同的，可能差别就跟“Transport”和“Transfer”之间的点点差别一样？
这样一来：传送“文件”、传送“邮件”、传送“REpresentational State”，这样不是很好吗？

58 楼 dlee 2008-05-08  

clia 写道

比如星际里面把一个人从一个星球传送到令一个星球，我们只看见两端的传送门，而看不见人是怎样被传送过去的，因此这个传输过程对我们是透明的，这正好适用于应用层的协议。

以这个观点来理解HTTP和REST是错误的。REST强调通过使用统一接口来实现操作语义对于中间组件的可见性，其目的并不是为了实现透明的传输。REST其实更强调中间组件的作用，而不是强调通信链两端组件的作用。与实现数据包的透明传输有关的工作TCP已经解决的非常好了，根本就不需要HTTP来解决。两位同学为何对“传输”一词如此执著？我很不解。不过只是一个动词，能否跳开“传输”这个词来思考问题。其实“传输”所直接对应的“transport”在技术论文中有很明确的含义，Fielding是不会随便乱用的。

leebai说应该将“传输协议”改为“传输层协议”，我觉得价值不是很大。至少我们以前在翻译这篇论文时，大家共同的理解“传输协议”就是“传输层协议”。现在按照你这样一改，既有“传输层协议”，还有很多应用层的“传输协议”，读者的脑袋不会爆掉才怪！

“transfer”在中文中并没有完全精确的动词与之相对应，这一点我同意。“转移”仍然不是非常准确，但是翻译为“传输”就更不靠谱了。

思而不学则殆，同学！

57 楼 leebai 2008-05-08  

<div class='quote_title'>clia 写道</div>
<div class='quote_div'>如果这样想的话，对“REST”这个缩写词的理解又更清晰了一点： <br/><br/>对于命名，这些大牛们应该是斟酌再斟酌的，应该会力求准确。既然用了“Transfer”，应该就是“Transfer”最被大众接受的意思，应该也会是跟FTP、SMTP里面的“T"一样的意思。 <br/><br/>这样说来，作者想强调的应该是：在HTTP上传送的不是文件，更不是邮件，而是“表形性状态”。 <br/><br/>（抱歉我又想换个新词，因为我觉得“Representational”翻译成“表形性”会更准确、贴切，这个词强调的应该是“形”上的东西，比如界面、文档，“表示”的话含义太宽泛，“表述”并没有牵扯到“形”。“表示层”我也是觉得叫“表形层”更能达意。） <br/><br/>也就是说，Web服务器输出的HTML、PDF、XLS等东西不应该被看作文件，而应该被看作资源的当前状态的“形”。（当然，如果有能力，也能提供资源的历史状态的“形”了。） <br/><br/>作者可能想修正HTTP命名中的“超文本”，觉得那还不够准确，没有抓住本质，因此才会提出“REST”这个新的缩写词。</div>
<p>真是。。。理越辩越明。 </p>
<p> </p>
<p>你的“表形性状态”我基本赞同，还有“最后一片乌云”是：</p>
<p> </p>
<p>Representational 除了表示“形”，是不是还表示Header！、Method、URI、reponse code 等“型”的信息？</p>
<p> </p>
<p> </p>
<p> </p>

56 楼 clia 2008-05-08  

如果这样想的话，对“REST”这个缩写词的理解又更清晰了一点：

对于命名，这些大牛们应该是斟酌再斟酌的，应该会力求准确。既然用了“Transfer”，应该就是“Transfer”最被大众接受的意思，应该也会是跟FTP、SMTP里面的“T"一样的意思。

这样说来，作者想强调的应该是：在HTTP上传送的不是文件，更不是邮件，而是“表形性状态”。

（抱歉我又想换个新词，因为我觉得“Representational”翻译成“表形性”会更准确、贴切，这个词强调的应该是“形”上的东西，比如界面、文档，“表示”的话含义太宽泛，“表述”并没有牵扯到“形”。“表示层”我也是觉得叫“表形层”更能达意。）

也就是说，Web服务器输出的HTML、PDF、XLS等东西不应该被看作文件，而应该被看作资源的当前状态的“形”。（当然，如果有能力，也能提供资源的历史状态的“形”了。）

作者可能想修正HTTP命名中的“超文本”，觉得那还不够准确，没有抓住本质，因此才会提出“REST”这个新的缩写词。

55 楼 leebai 2008-05-08  

clia 写道

既然“传输”不行，“转换”又不好听，不如翻译成“传送”得了。
“传输”更关心路上的过程，而“传送”更关心两端的情况。
比如星际里面把一个人从一个星球传送到令一个星球，我们只看见两端的传送门，而看不见人是怎样被传送过去的，因此这个传输过程对我们是透明的，这正好适用于应用层的协议。
这样FTP就可以叫做“文件传送协议”，SMTP就可以叫做“简单邮件传送协议”，岂不更贴切一点？而且也体现出了“Transport”和“Transfer”之间的细微差别！

嗯，这个“传送”也要比“转移”贴切的多。 至少采用这个译法就不会导致文中的state transfer 和
state transition混为一谈，导致很多读者将REST理解成以state transition为中心。

我更倾向于尊重中文传统翻译习惯，“传输”做普通多义词，而在表达网络概念时，见到Transport，根据语境分别翻译成“传输层”或普通“传输”。因为即使在应用层，英文有时候也会用transport表达，这时翻译成“传送”,好像也没有道理，像dlee那样在应用层甚至连中文“传输”都一概改成“转移”，就更不符合中文习惯了。

54 楼 clia 2008-05-08  

既然“传输”不行，“转换”又不好听，不如翻译成“传送”得了。
“传输”更关心路上的过程，而“传送”更关心两端的情况。
比如星际里面把一个人从一个星球传送到另一个星球，我们只看见两端的传送门，而看不见人是怎样被传送过去的，因此这个传输过程对我们是透明的，这正好适用于应用层的协议。
这样FTP就可以叫做“文件传送协议”，SMTP就可以叫做“简单邮件传送协议”，岂不更贴切一点？而且也体现出了“Transport”和“Transfer”之间的细微差别！

53 楼 leebai 2008-05-07  

<p>to dlee: <br/><br/>你说的都有道理。 <br/><br/><br/>我的理解角度是这样的：不管是6.5.3小节HTTP，还是第5章REST，其论述重点都是信息Transfer（传输or转移）“过程”中的问题，始终强调“中间组件”的作用；如果REST的重点是在服务端或客户端的“state transitions”，那就有点“文不对题”了。 <br/><br/>不管Tranfer翻译成什么，<span style='color: #ff0000;'>文章最大篇幅论述的东西，是文章的中心思想，应该是不会错的</span>。 <br/><br/>所以， <br/>HTTP is not a Transport Protocol <br/>具体怎么译，应该结合下面的论述文字来综合考虑，不能孤立地看问题。依我看，Fielding 应该把这句话写成： HTTP is not a Transport <span style='color: #ff0000;'>Layer</span>  Protocol 就不会有争议了，他想表达的应该就是这个：HTTP不是一个传输层协议。 </p>

52 楼 dlee 2008-05-07  

to leebai：

这个就看你如何理解HTTP协议了。很多人把HTTP看作一种能够穿越防火墙的简单易用的传输协议，仅仅是因为在HTTP的消息体中可以包含任意的内容。但是我们认为，HTTP协议所做的事情并不是“传输”。

王婆卖瓜一下，还是引用我们所翻译的那篇论文的译文，如果你对译文有歧义我们可以继续探讨：

Fielding 写道

2.1.2 应用软件vs. 网络软件
对于本论文范围的另外一个限制是我们将讨论范围局限在对于应用软件的架构的讨论上，不包括操作系统、网络软件和一些仅仅为得到系统支持而使用网络的架构风格(例如，进程控制风格[53])。应用软件代表的是一个系统的“理解业务”（business-aware）的那部分功能[131]。
应用软件的架构是对于整个系统的一种抽象，其中用户动作的目的可以被表示为一个架构的功能属性。例如，一个超媒体应用必须关注信息页面的位置、处理请求和呈现数据流。
这与网络的抽象形成了对比，网络的抽象的目的是将比特从一个地点移动到另一个地点，而并不关心为何要移动这些比特。只有在应用层面上，我们才能够基于一些方面来评估设计的权衡，这些方面包括每个用户动作的交互数量、应用状态的位置、所有数据流的有效吞吐量（与单个数据流的潜在吞吐量相对应）、每个用户动作所执行的通信的广度等等。

注意理解Fielding的这段话，这段话很关键。
传输层协议（例如TCP/UDP）以及其下的网络层协议（例如IP），都属于Fielding所说的“网络抽象”的范畴，它们主要的关注点是如何最高效地在来源和目的地之间搬运比特。它们不关心任何与数据包内容，确切地说是与数据包内容所包含的操作语义相关的知识。对于应用层协议来说，可以把它们看作无智能的搬运工，天生卖苦力的角色。

那么HTTP中的“transfer”是不是就是传输呢？我们认为不是，要不然我们就不好翻译这句话了：

Fielding 写道

HTTP is not a Transport Protocol

呵呵，不过这并不是我们将“transfer”翻译为“转移”的最主要原因（似乎一定要把“transport”和“transfer”翻译为两个动词）。

我们将“transfer”翻译为“转移”是因为我们确信至少在HTTP协议中，“transfer”的含义并不是“传输”。

如果把HTTP看作是一种“传输协议”，实际上只看到了HTTP消息体，而完全忽略了由几种HTTP动词、URI和HTTP头信息共同组成的HTTP包头所代表的语义。除了HTTP消息体以外，需要更多关注HTTP包头所包含的语义，很显然HTTP包头的语义并不是像TCP包头那样是用来寻址的。HTTP包头的语义是用来对服务器端的一个资源执行某种操作的。

在HTTP和REST中，“transfer”有两个含义：
一个含义是将HTTP服务器看成是一个由很多离散的资源构成的有限状态机，客户端软件（例如浏览器）通过点击一个超链接，或者通过提交一个表单，使得服务器从一个状态转移到另一个状态。

另一个含义是服务器将资源的一个状态封装为资源的一个表述（格式可以是HTML，也可以是XML或者JSON），转移到客户端。客户端对状态做一些修改，将修改后的状态封装为资源的另一个表述（格式可以是简单的表单数据，也可以是XML或JSON），转移到服务器，服务器根据接收到的新的表述修改资源的状态。

注意我在这里用的词并不是“传输”，而是一些人不习惯的“转移”。在汉语中，“传输”更多的是机械的动作，而“转移”更多的是人的动作，“转移”的智能要比“传输”更高。例如我们说：
我托张三把这包货转移给李四
而不说
我托张三把这包货传输给李四

我拿人来举例是有意的，因为HTTP协议就是故意设计为好像是两个人在对话：
GET http://www.iteye.com/topics/35
客户端：大哥，告诉我id为35的帖子说了些啥？
服务器：这篇帖子说的是....

POST http://www.iteye.com/topics
客户端：我要灌水，内容为...
服务器：ok，保存了

DELETE http://www.iteye.com/topics/35
客户端：我要删除id为35的帖子
服务器：ok，删除了

服务器端一个资源的状态被封装为资源的一个表述，在客户端和服务器端之间转移，并且导致服务器从一个状态转移到下一个状态，这就是HTTP和REST的本质。所以我们决定将HTTP翻译为“超文本转移协议”，将REST翻译为“表述性状态转移”。

另外REST还通过强调统一接口和操作语义的可见性，支持中间组件的工作。可以把HTTP通信看成是一个链条，其中除了两端的客户端和服务器外，还可以透明地插入很多中间组件，执行一些诸如缓存、安全审计等等方面的工作，以增强整个架构的可伸缩性和安全性。也就是说，状态的转移发生在整个HTTP通信链条上，而不仅仅发生在客户端和服务器之间。其他的几种协议例如FTP，并不支持中间组件的工作，所以我们看到HTTP服务器比FTP服务器的可伸缩性要好的多。

51 楼 leebai 2008-05-07  

to dlee:

transport”翻译为“搬运”，虽然是我的YY，但符合6.5.3小节作者要表达的情绪：“你们小看HTTP了，别它当做没有技术含量的搬运工”，YY一下有时候可以活跃气氛，要不然这种纯学术的文字看了累死人:-)。

将“transfer”也翻译为“传输”，只是尊重传统习惯，因为HTTP/FTP/SMTP/NNTP。。。都是这么翻译的。要说这些transfer的差别，确实很大。比如HTTP的transfer就比FTP复杂很多，但是SMTP的transfer也是比较复杂的。


“传输”纯粹是个现代词汇，我都怀疑港台不一定用它。

50 楼 dlee 2008-05-07  

leebai 写道

我反问你，FTP/SMTP/NNTP和HTTP有没有可比性？

这几个协议设计理念差别非常大。TCP/IP的4层协议栈，层次上越往上的协议，其设计理念和目标差别越大。你说到的这几个协议都是应用层的协议，除了它们都能使用TCP外，跟HTTP都没有多少可比性。至少到了HTTP 1.1版，HTTP的主要设计目标已经变成了REST这样一种新型架构风格的具体实现技术了，简单来说，HTTP协议就是用来实现REST架构的。
如果TCP翻译为“传输控制协议”（这是一个公认的翻译，比HTTP的翻译还要早很多年，我们就没有必要再去翻案了），那么HTTP的“transfer”是不是应该翻译为其他动词？至少我们认为HTTP中的“transfer”不应该也翻译为“传输”。为什么翻译为“转移”会更好，等会儿我说到HTTP协议客户端与服务器的交互方式时再来详细说。

你已经注意到了“transport”和“transfer”在英文语义上的差别了，这是你的一大进步。但是你有意把“transport”翻译为“搬运”，这是违反常规的。你坚持把“transfer”翻译为“传输”，也是有问题的。

在应用层出现了这么多的“传输协议”，HTTP/FTP/SMTP/NNTP，你不觉得是一件很奇怪的事情吗？

我做技术翻译比你要多一些，也积累了一些经验。根据我的了解，从技术层面上来说，“传输”这个词在英文中一般对应的是“transmission”或者“transport”，例如：
Transmission Control Protocol － 传输控制协议
Transport Layer - 传输层，你的意思是推翻所有前人的翻译，改成“搬运层”？

这两个词翻译为“传输”都不会引起什么歧义，但是将“transfer”也翻译为“传输”，是很值得怀疑的。不要想当然，这样翻译大可商榷。

49 楼 leebai 2008-05-07  

to dlee:

查了一下Transfer的各种用法，即使当“转移”、“迁移”解释，也是一个主体的“转移”、“迁移”，既“移”的前后是同一个东西。也就是说，该词并不适用于页面切换的情形，因为这种情况下其实是后来的Representational State 替换了前面的Representational State，而非某个Representational State自身的“移”，所以这种情况下也就只能用transition。

48 楼 leebai 2008-05-07  

dlee 写道

to leebai：
ok，等会儿再挑你译文中的刺，暂时先做个厚道人。

你告诉我：TCP协议和HTTP协议分别位于TCP/IP 4层协议栈中的哪一层？
如果它们并非位于协议栈中的同一层？这两层分别做些什么事情？它们在设计上主要的关注点分别是什么？

努力回忆一下自己以前上学时学到的或者自学学到的关于计算机网络方面的知识吧，如果你还没有忘记的话。

呵呵，不上你的当，不回答你的把人当弱智问题。。。。。

我反问你，FTP/SMTP/NNTP和HTTP有没有可比性？

刚才又看了一下你给的第一段原文，知道你是意有所指，不是随便摘的。该段论述确实容易让人以为Representational State Transfer的侧重点是在描述客户端发生的state transitions，问题是：


1、整篇论文有多少篇幅在讨论客户端state transitions？又有多少篇幅是讨论RES的传输过程？


2、如果REST真的要表达客户端页面切换的“state transitions”，为何不直接用没有岐义的"Representational State Transition"？


3、另外此时服务器端的state 并没有 transition，Representational State Transfer作为对整个HTTP的规划指南，只是从客户端看问题？

47 楼 dlee 2008-05-07  

to leebai：
ok，等会儿再挑你译文中的刺，暂时先做个厚道人。

你告诉我：TCP协议和HTTP协议分别位于TCP/IP 4层协议栈中的哪一层？
如果它们并非位于协议栈中的同一层？这两层分别做些什么事情？它们在设计上主要的关注点分别是什么？

努力回忆一下自己以前上学时学到的或者自学学到的关于计算机网络方面的知识吧，如果你还没有忘记的话。

46 楼 leebai 2008-05-07  

<div class='quote_title'>dlee 写道</div>
<div class='quote_div'>
<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>这个地方你确实错了，而且错得离谱。你先别急，我慢慢给你解释： <br/><br/>1、先说技术层面。你再仔细看看6.5.3小节的内容，作者在这里强调的是:不应该为了能够穿过防火墙，就把HTTP仅仅当作“搬运工具”。既：不要只看到HTTP能够把一个东西从A处搬运到B处的能力，而忽略了HTTP搬运的方式和过程(比如协议头标对“中间组件”【防火墙proxy等】在传输过程中的指导作用)。如果只是为了“搬运”(如SOAP over HTTP),就会忽略各种“中间组件”的作用，并且破坏防火墙的实际作用，如果仍期望防火墙起作用，其厂商就要增加额外的过滤（既阻止SOAP这样借壳上市）。 <br/><br/>总的来说，作者是在强调:HTTP的“传输行为本身”比“传输所达到的目的”更重要。 <br/><br/>2、再说英语语言层面。在英语中，transport和transfer都有“传输”的意思，但transport只是及物动词，transfer既可是及物动词也可是不及物动词，所以英语要表达“某某东西的传输协议”，正确的语法就是： Something Transfer Protocol,HTTP,FTP,SMTP,NNTP都是如此（如果要用transport，只能说Something transported Protocol），所以，之所以HTTP是 HyperText Transfer Protocol，并非因为你说的Transfer还有“转移”的意思，而是因为它可用做不及物动词。 <br/>如果你按你的翻法，FTP成了“文件转移协议”，SMTP成了“简单邮件转移协议”。。。整个互联网行业非崩溃了不可。。。。 <br/><br/>译文中凡是出现“转移”的地方，你自己读起来不觉得别扭吗？ <br/><br/>总而言之，你这个“HTTP并不是一种传输协议”的论调真是吓死人了，玩笑开大了，呵呵。 <br/><br/>当然，你们所作的工作我还是很佩服的，开发社区也应该感谢你们付出的劳动。MSN加你了，很喜欢和你讨论问题，虽然你认为我固执。</div>
<br/>我没有着急啊，你要比我着急的多，至少从你急于发表结论这一点来看。 <br/>把“transfer”翻译为“传输”，随便找一个中国人都会这样翻译，这样翻译看起来最直接，最简单。这就是“HTTP”被翻译为“超文本传输协议”的原因。 <br/>透露点内幕消息，其实我们最初也确实是将“transfer”全部翻译为“传输”的，但是后来经过再三讨论，改成了“转移”。其实“转移”或者“迁移”更能反映“transfer”在HTTP中的原意。 <br/><br/>你如果学习过OSI的7层协议栈，或者学习过TCP/IP的4层协议栈，应该能理解“传输层”、“传输协议”在其中的含义。HTTP里面的“T”并不是TCP中的“T”，含义上是有很大差别的。 <br/><br/>你来翻译一下以下这两段话，露上一小手，然后我们再继续深入讨论。 <br/>
<div class='quote_title'>引用</div>
<div class='quote_div'>REST was originally referred to as the "HTTP object model," but that name would often lead to misinterpretation of it as the implementation model of an HTTP server. The name "Representational State Transfer" is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use. <br/></div>
<br/>
<div class='quote_title'>引用</div>
<div class='quote_div'>6.5.3 HTTP is not a Transport Protocol <br/><br/>HTTP is not designed to be a transport protocol. It is a transfer protocol in which the messages reflect the semantics of the Web architecture by performing actions on resources through the transfer and manipulation of representations of those resources. It is possible to achieve a wide range of functionality using this very simple interface, but following the interface is required in order for HTTP semantics to remain visible to intermediaries. <br/><br/>That is why HTTP goes through firewalls. Most of the recently proposed extensions to HTTP, aside from WebDAV [60], have merely used HTTP as a way to move other application protocols through a firewall, which is a fundamentally misguided idea. Not only does it defeat the purpose of having a firewall, but it won't work for the long term because firewall vendors will simply have to perform additional protocol filtering. It therefore makes no sense to do those extensions on top of HTTP, since the only thing HTTP accomplishes in that situation is to add overhead from a legacy syntax. A true application of HTTP maps the protocol user's actions to something that can be expressed using HTTP semantics, thus creating a network-based API to services which can be understood by agents and intermediaries without any knowledge of the application.</div>
</div>
<p><br/><br/><br/>呵呵，dlee不厚道啊。。。翻译不是我的强项，我六级只考了六十几分。。。。。 <br/><br/>勉强翻译一下第二段（不喜欢你那种完全直译的风格，中文那样写很难读的:-)）： <br/><br/><br/><span style='color: #333399;'>6.5.3 HTTP 不是一个“搬运”协议 <br/><br/>HTTP不是作为“搬运”协议来设计的（既不只是把信息从一个地方搬到另一个地方）。他是一个传输协议，以通过传输及处理资源描述的方式对资源进行操作，来体现Web架构的语义。 </span></p>
<p><span style='color: #333399;'>
</span></p><p><br/>虽然这个精简协议用途广泛，但为了让中间层组件知道Web架构的语义，必须遵循协议，这也是HTTP能够穿过防火墙(中间层组件)的原因。 除了WebDAV，最近大多数HTTP的扩展提议，只是为了让其他应用协议能搭HTTP的便车通过防火墙，因此根本上都是馊主意：一方面导致防火墙形同虚设，一方面如果防火墙升级增加了协议过滤，这便车也就搭不成。由此可见，这类HTTP扩展是没有意义的，所制造的垃圾语法只能给HTTP带来无谓的开销。</p>
<span style='color: #333399;'>
<p><br/>真正的HTTP应用，应该把用户的行为映射成HTTP语义可以表达的东西，在此基础上，设计一个agents和中间层组件在不需了解应用细节的情况下也能读懂的的网络API。</p>
</span>
<p> </p>
<p/>
<p> </p>
<p><br/><br/>我对这个小节的理解是： <br/><br/>作者并不反对“<span style='color: #ff0000;'>传输</span>”，而是反对使用者忽略“<span style='color: #ff0000;'>传输过程</span>”，无视HTTP语义设计在“传输过程”中的控制作用。 <br/><br/>你把transfer 翻译成“转移”，除了让人徒生误解和降低译文的可读性外，没有任何好处。</p>
<p> 另外，你不能因为HTTP里面的“T”并不是TCP中的“T”，就因为TCP用了“传输”你就不能用，照这个逻辑，FTP的“文件传输协议”也必须改名了，还有其他XTP。。。咋整？</p>

45 楼 buaawhl 2008-05-07  

ltian 写道

buaawhl 写道

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

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

上述这些都是瞎想.

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

XML是最好的界面资源表达方式了(树型,结构化).XAML,XUL都不错.
不过,HTML仍然是最普遍的界面资源描述语言.浏览器就是HTML渲染器.

现在的浏览器界面仍然是单窗口的,顶多有个Tab,可以并列多个窗口.但仍然是单层的.
浏览器无法产生树型的多项联系的组合界面.如同TotalCommand那种.
客户端程序却很容易做到这种效果.
浏览器做这种效果.
HTML用Frame有缺陷, 用Portal布局+Ajax还是有缺陷.
最好的方法就是,客户端自由嵌入多个浏览器.每个小型界面中一个浏览器.专门显示HTML界面.
这些界面之间是有联系的.如同Frame那样.

44 楼 dlee 2008-05-07  

leebai 写道

这个地方你确实错了，而且错得离谱。你先别急，我慢慢给你解释：

1、先说技术层面。你再仔细看看6.5.3小节的内容，作者在这里强调的是:不应该为了能够穿过防火墙，就把HTTP仅仅当作“搬运工具”。既：不要只看到HTTP能够把一个东西从A处搬运到B处的能力，而忽略了HTTP搬运的方式和过程(比如协议头标对“中间组件”【防火墙proxy等】在传输过程中的指导作用)。如果只是为了“搬运”(如SOAP over HTTP),就会忽略各种“中间组件”的作用，并且破坏防火墙的实际作用，如果仍期望防火墙起作用，其厂商就要增加额外的过滤（既阻止SOAP这样借壳上市）。

总的来说，作者是在强调:HTTP的“传输行为本身”比“传输所达到的目的”更重要。

2、再说英语语言层面。在英语中，transport和transfer都有“传输”的意思，但transport只是及物动词，transfer既可是及物动词也可是不及物动词，所以英语要表达“某某东西的传输协议”，正确的语法就是： Something Transfer Protocol,HTTP,FTP,SMTP,NNTP都是如此（如果要用transport，只能说Something transported Protocol），所以，之所以HTTP是 HyperText Transfer Protocol，并非因为你说的Transfer还有“转移”的意思，而是因为它可用做不及物动词。
如果你按你的翻法，FTP成了“文件转移协议”，SMTP成了“简单邮件转移协议”。。。整个互联网行业非崩溃了不可。。。。

译文中凡是出现“转移”的地方，你自己读起来不觉得别扭吗？

总而言之，你这个“HTTP并不是一种传输协议”的论调真是吓死人了，玩笑开大了，呵呵。

当然，你们所作的工作我还是很佩服的，开发社区也应该感谢你们付出的劳动。MSN加你了，很喜欢和你讨论问题，虽然你认为我固执。

我没有着急啊，你要比我着急的多，至少从你急于发表结论这一点来看。
把“transfer”翻译为“传输”，随便找一个中国人都会这样翻译，这样翻译看起来最直接，最简单。这就是“HTTP”被翻译为“超文本传输协议”的原因。
透露点内幕消息，其实我们最初也确实是将“transfer”全部翻译为“传输”的，但是后来经过再三讨论，改成了“转移”。其实“转移”或者“迁移”更能反映“transfer”在HTTP中的原意。

你如果学习过OSI的7层协议栈，或者学习过TCP/IP的4层协议栈，应该能理解“传输层”、“传输协议”在其中的含义。HTTP里面的“T”并不是TCP中的“T”，含义上是有很大差别的。

你来翻译一下以下这两段话，露上一小手，然后我们再继续深入讨论。

引用

REST was originally referred to as the "HTTP object model," but that name would often lead to misinterpretation of it as the implementation model of an HTTP server. The name "Representational State Transfer" is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.

引用

6.5.3 HTTP is not a Transport Protocol

HTTP is not designed to be a transport protocol. It is a transfer protocol in which the messages reflect the semantics of the Web architecture by performing actions on resources through the transfer and manipulation of representations of those resources. It is possible to achieve a wide range of functionality using this very simple interface, but following the interface is required in order for HTTP semantics to remain visible to intermediaries.

That is why HTTP goes through firewalls. Most of the recently proposed extensions to HTTP, aside from WebDAV [60], have merely used HTTP as a way to move other application protocols through a firewall, which is a fundamentally misguided idea. Not only does it defeat the purpose of having a firewall, but it won't work for the long term because firewall vendors will simply have to perform additional protocol filtering. It therefore makes no sense to do those extensions on top of HTTP, since the only thing HTTP accomplishes in that situation is to add overhead from a legacy syntax. A true application of HTTP maps the protocol user's actions to something that can be expressed using HTTP semantics, thus creating a network-based API to services which can be understood by agents and intermediaries without any knowledge of the application.