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

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.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服务器的可伸缩性要好的多。

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那样在应用层甚至连中文“传输”都一概改成“转移”，就更不符合中文习惯了。

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

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

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

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

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

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

真是。。。理越辩越明。

 

你的“表形性状态”我基本赞同，还有“最后一片乌云”是：

 

Representational 除了表示“形”，是不是还表示Header！、Method、URI、reponse code 等“型”的信息？

 

 

 

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

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

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

思而不学则殆，同学！

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

 

你说我思而不学，我说你学而不思，多没意思啊?

 dlee同学，你最大的问题是：谈论问题时容易脱离问题本身，而对讨论者的个人能力、特质、习性妄下定义。面对面的交流也未必能真正了解一个人，更何况网络社区的交互信息交互能力是很有限的，你以为自己有超感知能力？

 

回归本题。其实这个HTTP/REST意涵问题、transfer问题，我们现在基本搞清楚了，就你还在糊涂。

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

 

应用层协议中，有一个RTP(实时传输协议，用于音视频系统)，其英文正式名称就是： Real-time Transport Protocol 。

RFC2616里也有这样的说法：。。。since  HTTP transports all message-bodies as payload 。。。(19.4.7)

 

 

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

 

 

你以后的翻译作品如果坚持应用层使用“转移”代替“传输”，小心书卖不出去，即使有人买了也不容易读懂。

赶紧把你的REST译文中的“转移”全换成“传输”，“HTTP不是一种传输协议”改成"HTTP不是一种传输层协议"，让更多的人能够从中受益。

 

我已经把你的译文打印成小册子了(版权？)，这个文章确实不错。以前还真没看过博士论文，认识软件系统的最高层次只到Specification级别，看来更高的纯理论层次才是技术的顶峰（或最低的基础）。你的评价“思而不学”，对，也不对，我不学的只是哪些末流东西，核心的东西还是稀饭的。