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

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

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

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

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

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

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

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

又翻了一下论文，为追求真义，还下了英文原文来看了一下，发现论文中最难翻的就是这个“representation”了。
如果“representational”可以翻成“表形性”的话，那“representation”又该如何翻？
资源的：“形象”？“外形”？“表现形式”？“表形”？“表示”？

从“transferring that representation”来看，还是翻成“表示”更合适，但“表示性状态”又会使人犯迷糊，真是难两全啊！

之前想不明白，除了HTML、JPEG等以外，XML、JSON这些不具“形”的东西（不是给人看，而是给机器处理），会不会算是作者所指的“representation”呢？可能是我理解错了，作者所指的representation并没有说一定要具“形”，被之前的“表示层”这样的概念误导了，以为“representational”都是要给人看的。

leebai的问题，Header！、Method、URI、reponse code 等应该是属于REST里的其他数据元素，如下表：

                 Table 5-1. REST Data Elements
         Data Element                      Modern Web Examples
resource                           the intended conceptual target of a hypertext reference
resource identifier              URL, URN
representation                   HTML document, JPEG image
representation metadata     media type, last-modified time
resource metadata             source link, alternates, vary
control data                      if-modified-since, cache-control

“透明的传输”好像是我说的，我是为了说明应用层协议应该使用传输层已经提供好的“透明的传输”。REST是应用层的架构风格，而在这种架构里已经包含了origin server、gateway、proxy、user agent这四种components，在架构内部足以实现缓存和安全，在它们之间的数据传输还是应该使用传输层的透明传输，所以这么说也没有错吧？

 

 

其他正文不细看，找这个倒挺眼贼。。。。 G.M.D.F.D.P  猜猜什么意思

模糊处理：把整个HTTP 消息看作Representational state 应该差不多。

还有个问题：普通GET request 消息算不算Representational state？ （它其实没什么state）。

我理解的Representational state 应该跟 representation是一个意思的，都是带资源状态的，都是用来在各components之间进行传送的。但直接叫“Representation Transfer”不太好，看不明白，而且没表示出状态。

GET应该是不带representation的吧，或者叫空的representation？

想了想，应该把整个request-response周期看作一次Transfer。

从这个角度思考，确实和服务器端资源状态之间的transfer更接近了。

你，你，你....水又要搞浑:

something move from A to B 才叫Transfer,东西还是那个东西只是位置变了. 
服务器state A replaced by state B  ,只能叫Transition，原来的东西已经没有了。Transfer没有这样用的。

to leebai：

好吧，这次算你说的对。

不过在这个论文中，至少有一个地方，你是说不通的：
6.4 Technology Transfer
难道翻译为“技术传输”？

反正我是不会把“transfer”全部翻译为“传输”的，翻译为“转移”就是为了显示出与“传输层协议”的区别。

啥这次，Transfer/Transition之异我前面的帖子也说过，你没仔细看。

6.4 Technology Transfer 翻译为“技术迁移”我不反对，但从正文三个小节的内容看，意译成“技术演化”是不是更好？


不是说“transfer”只能译为“传输”。http的transfer你译成“转移”语义上也没错，只是“数据在线路上的移动”这个“事”，大家已经习惯用“传输”来表达了（不单在transport layer，即使是两个网卡之间，双绞线上，硬盘连接线上，cpu与内存之间。。。），你那样写会增加读者的阅读困难。