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

“数据在线路上的移动”思考的层次还是太低了，基本上还是传输层的思维。“线路”这个概念在应用层已经不需要考虑了，应用层只需要确信底层协议能够提供可靠的“点对点通信”的支持，而不需要去关心通信的“线路”。

“数据的转移”意思是将应用层的多个通信参与者看作好像是具有高度智能的人，数据在他们之间转移，通信的参与者还会对数据做一些转换，执行一些操作。因为这个过程具有高度的智能，所以这个过程已经不能简单地以“透明的传输”过程来描述清楚了。

传输  ！＝ 透明的传输 ，传输就是传输，这个词和透明不透明没有关系（我前面的帖子也反复说过作者很强调Tranfer的“过程”及“中间组件”，因此认为它们是REST的“中心思想”）。就像你的“转移”，既看不出它表示透明，也看不出它不透明。

“数据传输”是被广泛接受的说法，在你们的译文中，为了回避传输这个词，把“传输编码”、“传输速率”。。。等常用词汇全变成了"转移编码"、“转移速率”、、、，所有的数据传递概念都用“转移”字眼，读起来真的很费尽。

此前没有人和你们反应过这些翻译问题吗？

to leebai：

我觉得不是什么大问题吧，大家投一下票，投票的人多了，改一下也是可以的。

不过“transfer”和“transport”全部都按照你的意思改为“传输”，后面Fielding又说“HTTP不是一种传输协议”，引起的歧义和混乱也会很大，所以这样改还是要慎重一些。

我不是跟你说了吗？这样翻译随便找个中国人都会，我们最初也确实是按照你说的做法翻译的，但是后来发现这样翻译问题很大才改过来的。你没有做过多少翻译，不是很清楚这里的两难局面。

你来提个修改方案，然后大家投票是否应该修改，按照票数多的来做。

我没用过JE的投票，没找到链接。

我的修改方案前面提到过：把transfer全翻译成“传输”，6.5.3标题翻译成“HTTP不是一种传输层协议”（加一个译注）

效果如下：

原译：



改译：



原译：



改译：

我来说两句。

首先，从google搜索的结果来看，老外对于transfer和transport也分得不是很清楚，比如这里：http://support.microsoft.com/kb/218155。不要怪M$，这样的例子其实还有很多。比如http://www.w3.org/Talks/9608HTTP/sld001.htm，特别注意这个1996年的演讲稿的作者其实也是HTTP协议的作者之一！！

我并不是说transfer/transport就没有语义上的区别，但是至少不是那么显著。个人理解transport偏向运输、运载、交通的含义。而transfer的含义更广泛一些。

其次，来看transport protocol，wikipedia在transport layer词条中有如下：

这段话是针对TCP/IP的四层或五层模型来说的。而针对OSI的七层模型，则有Transport Protocol Class 0（TP0）到Transport Protocol Class 4（TP4）。

无论哪一种，都可以认为transport protocol其实就是protocol on the transport layer，也就是“传输层协议”。联系Fielding说HTTP不是transport layer的语境，或许可以认为Fielding的意思就是说HTTP不是传输层协议（而是应用层协议）。

不过虽然我赞同transport protocol就是protocol on the transport layer，即点到点的通讯，但是无论如何，传输层协议和传输协议太过混淆。

我建议可考虑 传送 传递 等词。特别是 传递，我觉得比较有中介的概念——比如火炬传递，呵呵。

我也比较倾向于将“transfer”翻译为“传输”之外的某个动词。翻译为“传输”、“超文本传输协议”，我最大的担心就是“传输”这个动词与“传输层”联系过于紧密，存在着误导的可能性，会使得读者将注意力过多地集中于HTTP消息体，而完全忽略了HTTP包头所代表的语义。SOAP在这方面已经犯过一次大错了，其设计者想当然地认为HTTP只是一种能够穿越防火墙的传输协议。Fielding说“HTTP并不是一种传输协议”，很大程度上就是说给SOAP设计者这些曲解HTTP的人听的。《RESTful Web Services中文版》快出来了，在这本书中，大家对SOAP所犯的错误可以看得更清楚。

TCP与HTTP的区别在于：
TCP的使用者并不需要关心TCP包头的语义，TCP包头的语义对使用者来说是完全透明的。使用者需要的仅仅是TCP所提供的透明的点对点传输。
HTTP的使用者需要关心HTTP包头的语义，HTTP包头的语义对于使用者来说并不是透明的。使用者需要的并不仅仅是HTTP所提供的透明的点对点传输。这件事情TCP已经做的非常好了，用HTTP来做这件事情是多余了，而且还增加了HTTP包头额外的负载，从网络效率的角度来看是低效的，不够精益。

我们翻译为“转移”看来还不够好，可以将“转移”改为其他的动词。

单就HTTP来说，使用“传输”之外的词也是可商量的，要考虑的是：

1、中文文档传统习惯问题。如果没有把握扭转所有的应用层“传输协议”的翻译，单改一个HTTP翻译会引起混乱。

2、如何翻译应用层协议RTP(Real-time Transport Protocol)？新的翻译应该做到“自园其说”。

我觉得要看你怎么认识”企业应用“的”资源“了，不同于通常的资源型应用（如javaeye），企业应用的资源应该是流程（那些楼主认为stateful的咚咚）。
应该业是可以作到REST的

可能非常适合受权访问的数据库性企业应用

1 权限其实非常适合用rest方式编辑访问. 不用session和cookies是完全可以的。每个用户在服务器上可以有自己的数据空间用来存放信息 权限 文件.....。 访问这个路径下的信息需要通过http的验证 http://user@password:xmlshop.com/winterwolf/权限.xml

2 sql xquery 都可以直接当做资源来调用 post数据返回结果而已. xslt css javascript也可以作为资源来灵活调用。

3 同意布老大的观点 rest方式非常适合xmldb. sql数据库虽然也通过接口支持rest方式 但是不是自然的 关系数据库本身反rest