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

呵呵，dlee不厚道啊。。。翻译不是我的强项，我六级只考了六十几分。。。。。

勉强翻译一下第二段（不喜欢你那种完全直译的风格，中文那样写很难读的:-)）：


6.5.3 HTTP 不是一个“搬运”协议

HTTP不是作为“搬运”协议来设计的（既不只是把信息从一个地方搬到另一个地方）。他是一个传输协议，以通过传输及处理资源描述的方式对资源进行操作，来体现Web架构的语义。

虽然这个精简协议用途广泛，但为了让中间层组件知道Web架构的语义，必须遵循协议，这也是HTTP能够穿过防火墙(中间层组件)的原因。 除了WebDAV，最近大多数HTTP的扩展提议，只是为了让其他应用协议能搭HTTP的便车通过防火墙，因此根本上都是馊主意：一方面导致防火墙形同虚设，一方面如果防火墙升级增加了协议过滤，这便车也就搭不成。由此可见，这类HTTP扩展是没有意义的，所制造的垃圾语法只能给HTTP带来无谓的开销。

真正的HTTP应用，应该把用户的行为映射成HTTP语义可以表达的东西，在此基础上，设计一个agents和中间层组件在不需了解应用细节的情况下也能读懂的的网络API。

 

 

我对这个小节的理解是：

作者并不反对“传输”，而是反对使用者忽略“传输过程”，无视HTTP语义设计在“传输过程”中的控制作用。

你把transfer 翻译成“转移”，除了让人徒生误解和降低译文的可读性外，没有任何好处。

 另外，你不能因为HTTP里面的“T”并不是TCP中的“T”，就因为TCP用了“传输”你就不能用，照这个逻辑，FTP的“文件传输协议”也必须改名了，还有其他XTP。。。咋整？

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的规划指南，只是从客户端看问题？

to dlee:

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

这几个协议设计理念差别非常大。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”也翻译为“传输”，是很值得怀疑的。不要想当然，这样翻译大可商榷。

to dlee:

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

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


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

to leebai：

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

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

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

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

呵呵，不过这并不是我们将“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.javaeye.com/topics/35
客户端：大哥，告诉我id为35的帖子说了些啥？
服务器：这篇帖子说的是....

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

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

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

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

to dlee:

你说的都有道理。


我的理解角度是这样的：不管是6.5.3小节HTTP，还是第5章REST，其论述重点都是信息Transfer（传输or转移）“过程”中的问题，始终强调“中间组件”的作用；如果REST的重点是在服务端或客户端的“state transitions”，那就有点“文不对题”了。

不管Tranfer翻译成什么，文章最大篇幅论述的东西，是文章的中心思想，应该是不会错的。

所以，
HTTP is not a Transport Protocol
具体怎么译，应该结合下面的论述文字来综合考虑，不能孤立地看问题。依我看，Fielding 应该把这句话写成： HTTP is not a Transport Layer  Protocol 就不会有争议了，他想表达的应该就是这个：HTTP不是一个传输层协议。 

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

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

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