|
精华帖 (0) :: 良好帖 (18) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-05-07
buaawhl 写道
RPC和REST这两种风格都注定只是过渡产品.
赞成从更高的角度看问题，要想找更好的方案，就得跳出现有的所有框框。
|
| 返回顶楼 | |
|
发表时间：2008-05-07
dlee 写道
leebai 写道
Transfer是不是翻成“传递、传输”更好点？
我仔细检查了Fielding论文第5章对REST的描述，发现作者所描述的信息流动都是单向的，既，"表象状态RES"总是从服务端到客户端（中间可经过多层），也就是GET经历的过程；该章内容并不涉及“state”本身在服务器上的“变更（或迁移，Transfer的另一个意思）”。 [size=small;]补充：又看了一遍原文，基本确定dlee对“REST”的“T”的翻译是有问题的，Transfer就是指“状态”（或称信息、数据、资源 。。。Hypertext*）的“传输”，和HTTP的第三个T是一样的内涵，The Hypertext Transfer Protocol (HTTP)译为“超文本传输[/size]协议”，Representational State Transfer (REST)没有理由译成“表述性状态转移”。这么翻译有可能导致人们对REST的误解，以为REST描述的是“状态变更”问题。 继续补充：刚发现dlee在译文中（6.5.3小节），居然认为HTTP的传统翻译“超文本传输协议”不对。真是太荒谬了。看来经验再丰富的老手，也有糊涂的时候。 你确信自己读懂了论文的原文了吗？ 你确实在绝大多数时间都很自信，我就不在这里打击你的自信心了。按照你的个性，在这里交流很容易变成吵架和闹意气。 如果对REST真的有兴趣，加我的MSN吧：unruly_wind at sina dot com，我们私下深入交流一下REST相关的问题。另外也可以来这里交流： http://groups.google.com/group/rest_in_action leebai 写道
作者的意思是不是：POST/PUT/DELETE等其实都不是RESTful的本质，只有 GET+URI 才是RESTful的核心战斗力？
你啊，总是这么着急。这本书才读完了序言，就开始下结论了。慢慢来，兄弟！ 真把你招来了，呵呵。
这个地方你确实错了，而且错得离谱。你先别急，我慢慢给你解释：
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还有“转移”的意思，而是因为它可用做不及物动词。
译文中凡是出现“转移”的地方，你自己读起来不觉得别扭吗？
总而言之，你这个“HTTP并不是一种传输协议”的论调真是吓死人了，玩笑开大了，呵呵。
当然，你们所作的工作我还是很佩服的，开发社区也应该感谢你们付出的劳动。MSN加你了，很喜欢和你讨论问题，虽然你认为我固执。
|
| 返回顶楼 | |
|
发表时间：2008-05-07
ltian 写道 buaawhl 写道 在我的印象中, REST是Web Service的一种实现风格.另外一种实现风格是以SOAP为代表的XML RPC之类的技术规范. Web Service 的实现风格可以分为两种 : (1) RPC风格 (远程调用风格,XML格式的),以SOAP为代表 (2) REST PRC风格的问题在于多了一个信封,把地址,服务名什么都包在信封里面.因此是 Not Proxy Friendly. Proxy无法在URL的级别,判断客户需要的服务.必须要一个协议解析器(比如,SOAP协议)看到信封的里面,才能够发现需要的服务. REST风格就解决了这个问题, 需要什么服务,都写到URL里面. 如果我的记忆和理解都没有错的话.我就继续下面的猜想. -------------------------------------------------- RPC和REST这两种风格都注定只是过渡产品. (1) RPC风格,用XML表达函数名(服务名),返回值,参数列表,数据类型.非常蹩脚 XML就不是干这个的,XML是用来描述结构化层次数据的,尤其是树形结构数据. XML用来表达函数调用的语义,就非常不是当了. Spring的问题也在于此.如果Spring的配置文件格式不用XML,情况就会好得多. XML承担了太多本来不属于它,不适合它的工作. Web Service RPC风格的最终载体,我猜想,还是脚本.很可能是JavaScript. 因为JavaScript已经非常通用了,大量用在Web Page中,有很多各种平台的解析器. 从Ajax的发展,已经可以看出来了. (2) REST风格的要点,在于通用查询语句. 一条URL作为查询服务地址,查询条件,然后返回一系列数据(返回的数据同样包含了服务地址和查询条件,比如 ID, Name之类的). 我们可以把 REST服务器看作是一个数据库.可以是XML文档数据库,也可以是关系数据库. 不过,REST服务器表达关系数据服务有点力不从心. SQL太复杂了. REST服务器非常适合表达XML文档数据库. XPath天生就是用在URL中的. 从这点来看, REST服务并没有提供更多的超出XML文档服务器的工作. 而且,REST也远远达不到语义网所描述的目标. REST的主要意义,可能就在于打破人们对RPC风格的迷信. -------------------------------------------- REST风格是否适合"数据型企业应用". 如果查询条件简单的话,当然适合.而且非常适合.REST就是干这个的. 如果查询条件非常复杂,就不适合了. 授权不是问题,那只是多了一个验证, HTTP Header里面一个SessionID传来传去足矣. 业务流程复杂的企业应用,就只能采用RPC风格了. ---------------------------------------------- 关于RIA,如果还是基于浏览器.我猜想,也只能是过渡产品. 浏览器里面的RIA,再RICH,也RICH不过本地运行的客户端程序. Web Service Smart Client之类的东西,还稍微有点前途作为什么云计算的客户端. 浏览器会不会荒废?不会. 浏览器以后可能会作为最主要的界面展现器. 以后的本地客户端程序中,会嵌入浏览器. 而不是浏览器中嵌入RIA. 上述这些都是瞎想. 客户端嵌浏览器？？？？？真是大胆的想法？有什么好处呢？客户端的部署安装传统方式去部署吗？ 那还要里面嵌浏览器干什么，为了上互联网？还是有什么其它意想不到的需求？ 传统的桌面程序也有较WEB开发不便的地方，比如流式布局。甚至用嵌入式的浏览器去做比现在称为mashup的粒度更粗的集成。 |
| 返回顶楼 | |
|
发表时间：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. |
| 返回顶楼 | |
|
发表时间：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那样. |
| 返回顶楼 | |
|
发表时间：2008-05-07
dlee 写道
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.
另外，你不能因为HTTP里面的“T”并不是TCP中的“T”，就因为TCP用了“传输”你就不能用，照这个逻辑，FTP的“文件传输协议”也必须改名了，还有其他XTP。。。咋整？ |
| 返回顶楼 | |
|
发表时间：2008-05-07
to leebai：
ok，等会儿再挑你译文中的刺，暂时先做个厚道人。 你告诉我：TCP协议和HTTP协议分别位于TCP/IP 4层协议栈中的哪一层？ 如果它们并非位于协议栈中的同一层？这两层分别做些什么事情？它们在设计上主要的关注点分别是什么？ 努力回忆一下自己以前上学时学到的或者自学学到的关于计算机网络方面的知识吧，如果你还没有忘记的话。 |
| 返回顶楼 | |
|
发表时间：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的规划指南，只是从客户端看问题？ |
| 返回顶楼 | |
|
发表时间：2008-05-07
to dlee:
查了一下Transfer的各种用法，即使当“转移”、“迁移”解释，也是一个主体的“转移”、“迁移”，既“移”的前后是同一个东西。也就是说，该词并不适用于页面切换的情形，因为这种情况下其实是后来的Representational State 替换了前面的Representational State，而非某个Representational State自身的“移”，所以这种情况下也就只能用transition。 |
| 返回顶楼 | |
|
发表时间：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”也翻译为“传输”，是很值得怀疑的。不要想当然，这样翻译大可商榷。 |
| 返回顶楼 | |
