翻译是一份严谨的工作——关于HTTP中文翻译的讨论 博客分类： 读者点评/专家导读活动 HTTPtransfer传输中文翻译
讨论参与者共16位：
图灵谢工
杨博
陈睿杰
贾洪峰
李锟
丁雪丰
郭义
梁涛
吴玺喆
邓聪
胡金埔
臧秀涛
张伸
图钉派007LL
图钉派111DP
图钉派-34徐浩然
辩论主题：HTTP中的“transfer”是否应该翻译为“传输”？
主持人：图灵谢工
正方：贾洪峰、郭义、梁涛
正方观点：为了照顾读者的阅读习惯，还是应该继续沿用“超文本传输协议”这个称呼。
反方：陈睿杰、李锟、丁雪峰
反方观点：HTTP既然很清楚并不是一种“传输”协议，继续沿用带有巨大误导性的“超文本传输协议”这个名称，显然是不严谨、不妥的。
中立方：其余所有人
5月21日讨论内容：
杨博 16:56:35
已经出现过的术语含义会经常变化？
018图灵谢工 16:56:58
不好说
009陈睿杰-小狗 16:57:17
HTTP这个术语就是个例子
009陈睿杰-小狗 16:57:38
我很想知道，图灵的权威指南会怎么翻译这个词呢？嘿嘿
009陈睿杰-小狗 16:58:37
就HTTP
009陈睿杰-小狗 16:58:57
被dlee揪出来骂过很多次的，现在流行的翻译
018图灵谢工 17:00:16
超文本传输协议（Hypertext Transfer Protocol，HTTP）是在万维网上进行通信时所使用的协议方案。HTTP有很多应用，但最著名的是用于
web浏览器和web服务器之间的双工通信。
吴玺喆-George Wing 17:00:23
嗯，传输？！
018图灵谢工 17:00:33
HTTP起初是一个简单的协议，因此你可能会认为关于这个协议没有太多好说的。但现在，你手上拿着的是却一本两磅重 的书。如果你对我们
怎么会写出一本650页 的关于HTTP的书感到奇怪的话，可以去看一下目录。本书不仅仅是一本HTTP首部的参考手册；它是一本名副其实的web
结构圣经。
009陈睿杰-小狗 17:01:16
有对HTTP这个缩写做翻译解说么？不会又是“超文本传输协议吧”
009陈睿杰-小狗 17:01:27
要被dlee骂的
009陈睿杰-小狗 17:01:41
他的书里面都翻译成 超文本转移协议
009陈睿杰-小狗 17:01:50
我觉得可以在译者注那里说明下
009陈睿杰-小狗 17:02:20
这是个约定俗成的误解翻译，不就得了，两边不得罪
吴玺喆-George Wing 17:02:29
转移？!不习惯
018图灵谢工 17:02:48
一会我会发个前言的最新版帖子
吴玺喆-George Wing 17:02:51
传输？！不知道传输了神马。。。
009陈睿杰-小狗 17:03:00
这个问题，你们要问dlee了
杨博 17:03:10
transfer。。他为什么这么翻啊？
009陈睿杰-小狗 17:03:17
建议资讯下他
009陈睿杰-小狗 17:03:21
我觉得挺有道理的
LZSoft·梁涛 17:03:24
难道要翻译成变形么？
009陈睿杰-小狗 17:03:36
我找点笔记给你们参考
吴玺喆-George Wing 17:03:56
超文本转移协议
009陈睿杰-小狗 17:05:08
http://product.china-pub.com/member/bookpinglun/viewpinglun.asp?id=198630&t=2
009陈睿杰-小狗 17:05:15
看这里有个评论，是相关讨论
009陈睿杰-小狗 17:05:21
我个人是比较挺dlee的
009陈睿杰-小狗 17:05:42
这一条，展开了看看
018图灵谢工 17:05:50
我们这本翻译的译者陈涓比较权威
吴玺喆-George Wing 17:06:02
有链接吗？谢工
009陈睿杰-小狗 17:06:34
还是建议找李琨老师探讨下，哪怕是加个译者注也好啊
009陈睿杰-小狗 17:06:37
我的建议
018图灵谢工 17:07:11
陈娟是解放军理工大学的教授，谢希仁学生
吴玺喆-George Wing 17:07:30
实习了吗？
贾洪峰 17:07:43
HTTP的译法已经用这么多年了，我个人觉得不需要改了。
009陈睿杰-小狗 17:08:00
http://product.china-pub.com/57771#yzx
这本书的译者序就比较婉转
009陈睿杰-小狗 17:08:08
这样说明下，就两边都不得罪了
009陈睿杰-小狗 17:08:29
以Fielding博士设计的HTTP协议为例，大家都把它当做一种传输协议，但HTTP其实是为REST而生的，它能够表达状态和状态转移，这就是它
位于应用层而非传输层的原因，所以说HTTP中的Transfer被翻译成“转移”更为恰当。
吴玺喆-George Wing 17:08:29
丁雪丰
009陈睿杰-小狗 17:08:35
图灵的译者哦
吴玺喆-George Wing 17:08:38
他在群里呢
009陈睿杰-小狗 17:08:47
对啊，可以找他问问
杨博 17:08:58
嗯，这个挺有意思的
009陈睿杰-小狗 17:09:06
我看李琨老师也在线的嘛
贾洪峰 17:10:30
我也觉得加注更好一些。
杨博 17:10:38
关键术语的翻译对应的是关键概念的理解，我觉得还是挺重要的
009陈睿杰-小狗 17:10:50
不过估计来不及了，是不是都印刷了，下一版得了
018图灵谢工 17:11:21
我看看最新的前言
贾洪峰 17:11:49
可以注明，因为传统原因，大家一直译为“传输”，实际应为“转移”，等等。
009陈睿杰-小狗 17:11:56
对
贾洪峰 17:12:18
像微软的官方文档中都一直用传输，突然冒出一个“转移”来，很难为大家接受。
LZSoft·梁涛 17:12:45
这一点日文比较好，一直挺统一。
贾洪峰 17:12:56
那是因为日文的少。:)
LZSoft·梁涛 17:13:10
跟日文本身有点关系。
LZSoft·梁涛 17:13:20
没有太多含糊和意义重合的词。
贾洪峰 17:13:40
这是Ｍｉｃｒｏｓｏｆｔ的文档
018图灵谢工 17:13:52
目前我看了，这本书叫传输
LZSoft·梁涛 17:14:28
session => セッション
LZSoft·梁涛 17:14:35
直接音译。
LZSoft·梁涛 17:14:43
很少有重合的。
009陈睿杰-小狗 17:14:44
正文不用改，就加个说明就最好
贾洪峰 17:15:21
这是微软给的定义，如果从deliver的角度来说，叫传输也未尝不可。
LZSoft·梁涛 17:16:40
“递送”呢？
009陈睿杰-小狗 17:17:46
dlee怎么不出来讨论下
杨博 17:20:57
中文译名问题
HTTP在*被翻译为“超文本传输协议”，因为“transfer”在此有“传输”的含意。但HTTP定制者之一的Roy Fielding博士在其论文
[1]（6.5.3节）中使用“transfer”表达的是“（表述状态的）转移”（Representational State Transfer），而不是“传输”。这是因为
英语单词“transfer”在不同语境下的多义性，请勿误解。
另一方面看，不管在大陆还是港台地区，应用层协议名字中的“transfer”习惯上都被译为“传输”，1991年，Tim Berners-Lee发明设计
HTTP的最初目的很单纯，就是为了传输含有超链的文本，最初版本的HTTP只能传输纯文本页面，只有一个GET方法，并不适用于构建各种应用
系统，这里HTTP（超文本传输协议）与FTP（文件传输协议）、NNTP（网络新闻传输协议） 、SMTP（简单邮件传输协议）相比，并无特别之
处。HTTP流行之后，Roy Fielding2000年论文提出的Representational State Transfer，是HTTP（也可以是其他传输协议）之上构建各种应
用系统的一种架构风格，其中的“State Transfer（状态转移）”并未改变“Hypertext Transfer（超文本传输）”的原始含义，由此看“
超文本传输协议”的译法并无不妥。
杨博 17:21:01
wiki上的
贾洪峰 17:23:22
没有深入研究过这些论文，所以不太好说。
贾洪峰 17:23:41
我是仅从尊重习惯的角度来考虑的，哪怕是错误的习惯。
009陈睿杰-小狗 17:23:46
所以才想让论文的译者来讨论下了，但是貌似他qq没回复
LZSoft·梁涛 17:23:46
Wiki不是很权威，感觉。
018图灵谢工 17:23:55
一会我把这本书的前言部分给大家看看放社区文章内
009陈睿杰-小狗 17:24:01
可以不修改翻译，但是加个注释说明下，个人建议
LZSoft·梁涛 17:24:08
毕竟Wiki也是大量非专职人士贡献的。
贾洪峰 17:24:12
大家还记得物理中的磁场强度和磁感应强度吧？！
杨博 17:24:25
嗯，我在看这段是谁加的
杨博 17:24:49
wiki上也有很多专业人士的说
李锟 17:25:43
这个解释让Fielding看到后会怎么说呢，Fielding在2000年的论文中就说的很清楚“HTTP不是一种传输协议”。某人非要指鹿为马说HTTP其
实本质上就是一种传输协议，是为了证明什么呢？
009陈睿杰-小狗 17:26:27
欢迎李老师加入讨论，我个人是比较认同的
吴玺喆-George Wing 17:27:12
感觉很有料
李锟 17:27:22
Fielding就是HTTP 1.1协议的原创者，尊重一下原创者的观点，这个要求似乎不过分吧？
吴玺喆-George Wing 17:27:54
有时候 事物的发展远远超出了发明家的想象
009陈睿杰-小狗 17:28:13
但是论文里面明确说明了赛
009陈睿杰-小狗 17:28:33
总不至于和他的意思相悖吧
吴玺喆-George Wing 17:28:36
造物主说自己的造的物是 转移协议，人们还是在说：传输协议
郭义 17:29:05
中文里面 转移和传输。有什么差异？
LZSoft·梁涛 17:30:11
类似于拥有权和控制权吧。
009陈睿杰-小狗 17:30:39
传输的是实体内容对吧，但是抽象的资源只能是转移表述
李锟 17:31:09
仔细看一下《REST实战》等等图书。把HTTP传输协议当作一种传输协议来使用，是非常低效的，这个Web开发界早就有共识了。
邓聪 17:31:37
你前提是REST的场景
009陈睿杰-小狗 17:31:42
所以建议HTTP权威指南能译者注说明下，不要再以讹传讹了
邓聪 17:32:09
就C到S这样一个HTTP应用协议来说，传输没有什么不妥
杨博 17:32:42
嗯，09年wiki的版本是这样的“中文译名问题
HTTP 在*被翻译为“超文本传输协议”，因为“transfer”在中文里有“传输”的含意。但依据 HTTP 定制者之一的 Roy Fielding
博士的论文[1]（6.5.3节），作者专门强调“transfer”表示的是“（表述状态的）转移”（Representational State Transfer），而不是
“传输”（transport）。故其中文译名“超文本传输协议”恰恰引种反映了这种误解。更符合原义的译名应该为“超文本转移协议”。”
吴玺喆-George Wing 17:33:37
晚出了十几年
009陈睿杰-小狗 17:33:39
我还等着看呢，囧
吴玺喆-George Wing 17:33:53
等得花儿都谢了
郭义 17:33:59
超文本转移协议 貌似也很难理解到 状态转移。。。
李锟 17:34:16
2002年的老书，不过HTTP 1.1从1999年到现在一直没出新版本。
009陈睿杰-小狗 17:34:20
建议大家都看看论文好了，看过了就会有个大概理解了
吴玺喆-George Wing 17:34:28
随便一本 TCP/IP 相关的书都有http的部分
郭义 17:34:29
不如叫超文本状态转移协议。。。多清晰。。
009陈睿杰-小狗 17:34:31
好歹是HTTP制定者的看法
吴玺喆-George Wing 17:34:49
最重要的就是 缓存机制了
杨博 17:34:57
哈哈，不小心看到roy fielding的这篇博士论文就是@李锟翻译的
李锟 17:35:05
Google不是搞了一个自己的HTTP协议吗，Chrome浏览器和Google自己的网站支持。
009陈睿杰-小狗 17:35:07
小吴，你可以去看 REST实战
009陈睿杰-小狗 17:35:21
里面把HTTP的优势都讲了
吴玺喆-George Wing 17:35:32
浏览器 缓存 中间代理 缓存 服务器 缓存 三层缓存
009陈睿杰-小狗 17:35:37
我看完了，大部分能理解，就是 超文本驱动，这个还有点模糊
009陈睿杰-小狗 17:35:47
不止是缓存，还有很多东西
009陈睿杰-小狗 17:36:02
比如分布式、无状态、容错
吴玺喆-George Wing 17:36:19
难点 重点 是在 HTTP 缓存
吴玺喆-George Wing 17:36:36
协议 我打印了呀
009陈睿杰-小狗 17:36:37
这个没有多难啊，我倒是觉得
009陈睿杰-小狗 17:36:47
书里面都讲了，强烈推荐
LZSoft·梁涛 17:36:51
怎么看都像协程的网络版实现。
吴玺喆-George Wing 17:37:33
在中间代理层的缓存 你怎么用长连接 分块传呢？
吴玺喆-George Wing 17:37:50
实践起来 还是有很多坑的
009陈睿杰-小狗 17:37:50
http本来就不是给你做长连接用的
009陈睿杰-小狗 17:37:59
你就是在滥用
009陈睿杰-小狗 17:38:03
无状态是什么意思
郭义 17:38:13
1.1 支持长的吧。
009陈睿杰-小狗 17:38:36
要comet，还是老老实实的用web socket好了
吴玺喆-George Wing 17:38:37
IE6是个大坑
009陈睿杰-小狗 17:38:51
看书啦看书啦，你们都不看书
009陈睿杰-小狗 17:39:07
我是菜鸟，只能这么说了，反正书上这么讲的
LZSoft·梁涛 17:39:10
没心情看，太多坑要填。
郭义 17:39:12
http 的长连接。很重要的哦。。。
009陈睿杰-小狗 17:39:15
实际中我也会遵循
吴玺喆-George Wing 17:39:26
试试IE6吧
009陈睿杰-小狗 17:39:29
要真长连接，我会考虑socket
009陈睿杰-小狗 17:39:37
IE6可以淘汰了
LZSoft·梁涛 17:39:37
用HTTP长连接不符合它的设计宗旨。
吴玺喆-George Wing 17:39:48
绝对 的巨大的 埙石坑
009陈睿杰-小狗 17:39:54
无状态这么重要的要求，你们都不遵循
009陈睿杰-小狗 17:39:58
我也没什么好说的了
郭义 17:40:01
太学术了。。。技术是为了解决实际问题为好。。
李锟 17:40:25
无状态怎么是太学术了？这样说简直就是无知了。
009陈睿杰-小狗 17:40:27
一个session就能搞死你
郭义 17:40:38
我是说。。。长连接。。。
009陈睿杰-小狗 17:40:39
session复制？omg，你慢慢同步去吧
009陈睿杰-小狗 17:40:53
长连接不就是违反了无状态的一个特例么
吴玺喆-George Wing 17:41:08
HTTP有无状态，在实践国还是得有状态
009陈睿杰-小狗 17:41:11
项目里面现在都是轮询
吴玺喆-George Wing 17:41:15
实践中
吴玺喆-George Wing 17:41:24
轮询不好
009陈睿杰-小狗 17:41:38
长连个个毛线，ajax轮询了，等下个版本，让客户用特定的浏览器，我用web socket了
郭义 17:41:49
尽信书不如无书。。
009陈睿杰-小狗 17:41:59
后台配合Node，不是更好的选择么
LZSoft·梁涛 17:42:04
工程派跟学院派对上了。
018图灵谢工 17:42:10
你们在争什么，我都看不懂
009陈睿杰-小狗 17:42:23
我就不相信你们在实际项目里面真的做到非轮询的长连接了
LZSoft·梁涛 17:42:25
他们争的是 是否实用。
李锟 17:42:26
别扣帽子，中国人最傻的就是乱扣帽子。
009陈睿杰-小狗 17:42:34
发个永远下载不完的页面？
李锟 17:42:37
无状态对于服务器的可伸缩性是至关重要的。
杨博 17:42:38
嗯，我也看不懂，不过语气很犀利啊
009陈睿杰-小狗 17:42:40
不觉得很那啥么
009陈睿杰-小狗 17:43:21
而且，我想知道，现在有多少产品HTTP服务器，能够经受得住你们的长连接
邓聪 17:43:35
见过的 一般都是轮询
009陈睿杰-小狗 17:43:39
web qq这么做的么？服务器恐怕早就over了
邓聪 17:43:58
拉 推相结合
郭义 17:44:09
陈睿杰-小狗 很多http长连接的应用可能你没注意。。并不只是comit才算长连接应用。
009陈睿杰-小狗 17:44:15
HTML5的web socket真的很好
018图灵谢工 17:44:22
http://www.ituring.com.cn/article/1806
009陈睿杰-小狗 17:44:31
我指向知道http长连接能经受多大的负载
009陈睿杰-小狗 17:44:36
就这个问题，其他的我不问了
009陈睿杰-小狗 17:44:42
qq会不会这么做
图钉派-34徐浩然 17:44:51
qq用了flash
吴玺喆-George Wing 17:44:53
有场景 可以用到呀
018图灵谢工 17:44:54
我发了有关这书的内容
图钉派-34徐浩然 17:44:57
某种意义上可以算是长连接
009陈睿杰-小狗 17:45:00
局域网里面你玩玩无所谓的
郭义 17:45:11
如果没有１.１的长连接。。。大量请求server 也是很多问题的。
009陈睿杰-小狗 17:45:14
flash可以socket的好不好
018图灵谢工 17:45:21
一本名副其实的 Web架构“圣经”——关于《HTTP权威指南》
018图灵谢工 17:45:26
这标题，估计要被拍
009陈睿杰-小狗 17:45:34
http的无状态，正好能解决你的大量请求的问题
郭义 17:45:44
这么说吧。有个应用 叫ad exchange。。你可以了解下。。
邓聪 17:45:47
这本书终于要出了
009陈睿杰-小狗 17:45:53
算了，我也不争论了，只是希望大家去看看REST相关的书
LZSoft·梁涛 17:46:02
同小狗。
009陈睿杰-小狗 17:46:12
顶楼上
郭义 17:46:35
有个环节叫 RTB。。也就是有大量访问。。
郭义 17:47:14
qps 大约。每妙。要２万。。。如果用短连接要很多机器的。。
009陈睿杰-小狗 17:48:08
可以负载均衡哟
009陈睿杰-小狗 17:48:20
因为没有状态信息，1000台机器都是一样的哟
吴玺喆-George Wing 17:48:22
要吵 才有收获呀
邓聪 17:48:33
10年在推特上 看到yurii 推荐过这本书 看下时间，国外2002出版，感觉一下落后太多了
009陈睿杰-小狗 17:48:47
没有会话信息，你不用管到底之前是哪台服务器收到了请求，嘿嘿，好了，点到为止，不争论了
邓聪 17:49:00
都开始丢名称了么，哈哈哈哈
邓聪 17:49:06
名词
郭义 17:49:08
qps２万。上了负载 后面也得不少机器的。
邓聪 17:49:31
神马应用啊？
郭义 17:49:50
dsp 进行rtb 竞价。。
郭义 17:50:00
也就是个实时竞价 架构。。。
郭义 17:50:32
现在google 的adexchange . 淘宝的tanx。。都是这个应用。。
郭义 17:51:18
我这是个实际问题。。说一下没别的意思。。。就是部想让大家从一个误会走如另一个误会。。
LZSoft·梁涛 17:52:25
但凡是个工程师，都会觉得能解决问题就成。至于学术上爱叫什么名字都无所谓。只是个名字罢了，能达成共识就行了。
说重一点，委员会为什么令人讨厌？因为他们跟长连接一样，消耗的资源比解决的问题多。
应用场景不一样，纠结在一个名字上有什么意思呢。
回家啃《黑客》去了。各位继续。
009陈睿杰-小狗 17:53:14
哈哈，钝刀，你还没看完黑客么
LZSoft·梁涛 17:55:54
刚开始啃。
LZSoft·梁涛 17:56:03
挺好看的。
LZSoft·梁涛 17:56:25
里面有些秘史一类的东西。
018图灵谢工 17:58:53
一本名副其实的 Web架构“圣经”——关于《HTTP权威指南》http://t.cn/zO3ApYN ，本书是计算机专家多年实践经验的总结，介绍了技术
人员为了高效使用HTTP所需要知道的一切。本书即将于6月出版，市场上专门介绍HTTP的书几乎没有，本书是第一本。欢迎大家到图灵社区发
表高见。
018图灵谢工 17:59:00
我这么说，没问题吧
018图灵谢工 17:59:58
这句话表述，有问题没
009陈睿杰-小狗 18:00:50
“全面”介绍的没有
009陈睿杰-小狗 18:00:56
要说没有，那太假了
009陈睿杰-小狗 18:01:04
那些REST书都讲了不少
王旭泉 18:01:08
市场上专门介绍HTTP的书几乎没有，本书是第一本。。。有点罗嗦
018图灵谢工 18:01:14
市场上专门全面介绍
018图灵谢工 18:01:54
让大家拍砖吧
009陈睿杰-小狗 18:03:25
书名都叫权威指南，就说是介绍HTTP相关知识最权威的资料不就得了
018图灵谢工 18:03:39
本书不仅仅是一本 HTTP首部的参考手册，它还是一本名副其实的 Web架构“圣经”。
018图灵谢工 18:03:49
这些话都是这本书原书中所述的
009陈睿杰-小狗 18:04:49
是够厚的
009陈睿杰-小狗 18:04:59
中文版多少页
018图灵谢工 18:06:27
一般原英文书的页数打个8折左右就是中文的页数
018图灵谢工 18:06:57
想想作者写本书真的不易，还是向作译者们都致敬吧，太不容易了
贾洪峰 18:09:07
随着年龄的增长，更能体会别人的不易。
贾洪峰 18:09:31
也就不那么容易大动肝火了
018图灵谢工 18:10:15
没事，都拍我们，咱胆子越来越小，越来越不敢出书了，也不知是好事，还是坏事呢
018图灵谢工 18:10:32
贾老师，看看这译文感觉如何
018图灵谢工 18:11:18
我会及时反馈意见给译者和编辑，包括今天大家提出的传输的说法
贾洪峰 18:11:18
我就愿意干挑刺的活儿。哈哈
018图灵谢工 18:11:50
贾老师，你这手上翻译的书，份量也极重啊
贾洪峰 18:11:54
不干活的总是有理的。:)
018图灵谢工 18:11:58
是在翻译《计算机体系结构》吧
贾洪峰 18:12:08
所以我现在提心吊胆的。
贾洪峰 18:14:31
有英文稿吗？
018图灵谢工 18:14:45
好象网上应该有
贾洪峰 18:15:30
最后一句不通，少了一个“的”字吧，这个不用看原文。:) 本书的译者是来自解放军理工大学通信工程学院陈涓老师。
018图灵谢工 18:15:49
这是我刚写的
018图灵谢工 18:16:23
本书译者是来自解放军理工大学通信工程学院的陈涓老师。
5月22日讨论内容：
018图灵谢工 10:46:24
丁雪丰，HTTP这个传输和移送的翻译问题，是不是一定要改过来
丁雪丰 10:47:03
移送？什么移送？
李锟 10:47:49
就是昨天一群牛人整来争去的那个transfer是否翻译为传输的问题
018图灵谢工 10:48:06
HTTP 在*被翻译为“超文本传输协议”，因为“transfer”在中文里有“传输”的含意。但依据 HTTP 定制者之一的 Roy Fielding
博士的论文[1]（6.5.3节），作者专门强调“transfer”表示的是“（表述状态的）转移”（Representational State Transfer），而不是
“传输”（transport）。故其中文译名“超文本传输协议”恰恰引种反映了这种误解。更符合原义的译名应该为“超文本转移协议”。”
李锟 10:48:42
我参与了几句，后来发现某些人实在太牛了，比HTTP 1.1原创作者Fiedling还要牛数倍。只好不敌而退。
018图灵谢工 10:48:58
李老师，那个Fielding老师论文的那句话给我们一下，我们转告译者
丁雪丰 10:49:36
我是觉得有些约定俗成已经深入人心的翻译，可以保留原来的翻译，但加以标注。或者就索性不翻译了，保留原文，加译注。但是，这个意
思还是要加以正确说明和引导的，不能一直误解下去。
018图灵谢工 10:50:05
是的，我们也是要这样做的
张伸 10:50:13
同意不翻译加译注说明和引导。
李锟 10:50:25
http://www.ituring.com.cn/article/937 请仔细看一下我以前写的blog：为何HTTP被翻译为“超文本传输协议”是一次历史上的重大翻译
错误？
018图灵谢工 10:51:25
感谢李馄老师，纠正我们
018图灵谢工 10:52:10
如果能全文通改，我们就尽量改，如果不能通改，我们想办法加以显著位置的说明
丁雪丰 10:52:29
所以我在我那本书里，就是HTTP缩写不翻译，Hypertext Transfer Protocl完整表达，我就没翻译。但出现处，我加了译注。加译注是个关
键，要告诉读者，虽然我没写中文，但是我告诉你他是什么意思，应该怎么理解。
170姚琪琳 10:52:59
李老师，群里没人质疑您对HTTP的翻译
李锟 10:53:26
陈涓老师最好能与我和小丁交流一下，陈老师的主要工作毕竟不是Web开发。
018图灵谢工 10:54:21
我感觉，也许学校的所有教材或教学都没改过来
丁雪丰 10:54:32
有些人就喜欢“传输”，看到“转移”觉得有问题，那是他们理解的问题，但我们还是有义务把问题说清楚。一板砖拍死谁对谁错，估计谁
都不买账。引导为主吧。
丁雪丰 10:55:53
是的，大家都看超文本传输协议看惯了，你一改，他就觉得你有问题，所以当时我和李锟商量了好久，我最后决定不翻译加译注，最后还把
我们的讨论写在了书的序言里。
李锟 10:56:58
transfer留着不翻译也行，习惯性地翻译为“传输”肯定是错误的。
018图灵谢工 10:56:59
我刚和QA部的几位同事说了，他们很重视，这书已经复审完成，就在排版校对了，所以会停下补充说明
胡金埔 10:57:43
什么书？
018图灵谢工 10:58:01
HTTP权威指南
杨博 10:58:01
嗯，可以考虑后面附上一篇讨论的文章
李锟 10:58:04
Hypertext Transfer Protocol，不要再直接翻译为“超文本传输协议”了。这是我的呼吁。
018图灵谢工 10:58:34
我们编辑也说，这个错误年代太久了，图灵不应该再犯了
胡金埔 10:59:00
好书。
009陈睿杰-小狗 10:59:19
嗯，这就对了
009陈睿杰-小狗 10:59:35
喜欢图灵严谨的态度，也不枉我昨天提起这事儿
018图灵谢工 10:59:59
非常感谢，衷心感谢大家，昨天晚上我回家看了一些文档，感觉问题比较严重
170姚琪琳 11:00:07
读者之幸
李锟 11:00:10
HTTP不是一种传输协议，Fielding很多年来在很多场合强调过。这是理解HTTP协议本质的入门点。
009陈睿杰-小狗 11:00:35
关键的问题是，不能一错再错
018图灵谢工 11:00:57
书好不好另说，出版者的主要职责要对读者负责任，不能出伪科学的东西
郭义 11:01:05
李锟(44035001) 11:00:10
HTTP不是一种传输协议，Fielding很多年来在很多场合强调过。这是理解HTTP协议本质的入门点。 那这么说。。国外一直理解也不是对的。
。这就和翻译没什么关系了。
009陈睿杰-小狗 11:01:28
又要钻牛角尖了
009陈睿杰-小狗 11:01:36
是要继续错下去么
李锟 11:01:41
HTTP其实是一种应用协议。不过本着人有多大胆地有多大产的革命乐观冒险主义，非把HTTP当作传输协议来用，确实也死不了人。但是这是
低效的用法，会付出一些代价。
郭义 11:02:00
哇哈哈。。
018图灵谢工 11:02:06
其实是翻译背后隐藏着更深的问题
009陈睿杰-小狗 11:02:28
http老爹其实会很伤心的，自己生了个儿子，别人非要说是女儿
018图灵谢工 11:02:44
要知道一本书的传播速度和影响力是很远的
李锟 11:03:07
昨天有些同学反复争论架构设计的某个点能否达到最大化，这是没有意义的。这些同学不理解其实架构设计就是权衡的艺术，一味追求某方
面，就会忽视其他方面。
009陈睿杰-小狗 11:03:33
其实最好的办法还是丁老师那样，不做翻译，然后译者注澄清一下这个问题
李锟 11:04:20
HTTP协议为何要这样设计、设计出来是为了做什么事情，指导思想是REST。REST其实就是中庸之道，没什么神秘。
009陈睿杰-小狗 11:06:30
建议大家多看看书，那本 REST实战 我觉得是目前看过的讨论最深入的，推荐
009陈睿杰-小狗 11:06:44
权威指南这本，我也要收藏一本做参考
018图灵谢工 11:06:56
感谢@dlee_cn @DigitalSonic @琳琳的小狗 等大家的意见，本书对HTTP的译法“超文本传输协议”，和实际的译法”超文本转移协议“，会
和译者沟通后，在重要位置做说明。
018图灵谢工 11:07:03
我这样写一下
009陈睿杰-小狗 11:07:22
嗯，反正改不改正文无所谓，但是一定要说清楚
009陈睿杰-小狗 11:07:54
名词被误传了不是问题，只要大家知道真正的含义就行了
009陈睿杰-小狗 11:08:28
如果大家都明白HTTP被发明的初衷，这个词的叫法其实也无关紧要，但是现在的关键是，很多人理解就有问题
贾洪峰 11:17:57
我现在在想，这个是中国人错误理解了Transfer，还是英美人也错误理解了Transfer
贾洪峰 11:19:13
如果是因为Transfer对应于中文的“传输”和“转移”，而最初的翻译者错用了“转移”，那就绝对是因为错误翻译而导致误解。
但如果国际上的大多数人也认为Transfer是delivery information，那就和翻译没有任何关系了。
009陈睿杰-小狗 11:19:36
现在的事实是，中文名词翻译就错了，你说是谁的错
009陈睿杰-小狗 11:19:57
好比卖刀的，卖给你，你杀人了，是要怪商贩么
贾洪峰 11:20:46
您没明白我的意思。
009陈睿杰-小狗 11:20:54
没有任何迹象表名，国际上“大多数”人也认为ransfer是delivery information
009陈睿杰-小狗 11:21:19
这个论据本来就站不住脚
贾洪峰 11:21:49
我说的是如果！
009陈睿杰-小狗 11:22:10
那你说的没错
李锟 11:36:30
首先要明确一下，transfer这个词语，在HTTP/FTP这些IETF协议中，和transport有明确的区分。本身根本就没有“传输”（transport）的
含义，几乎从来不会与transport混用。
李锟 11:37:17
思而不学则殆，同学们。把HTTP或者FTP协议中找一段出来，大家一起分析一下transfer到底说的是什么。
图钉派111DP 11:37:28
讨论来这里
http://zh.wikipedia.org/wiki/Http
李锟 11:38:38
写到*，是个很好的想法
郭义 11:38:42
其实我觉得吧。。
009陈睿杰-小狗 11:40:48
确定不是被kill掉的？哈哈
贾洪峰 11:45:46
1991年，Tim Berners-Lee
Roy Fielding
这两个人是什么关系？
贾洪峰 11:45:58
合作者？
LZSoft·梁涛 11:46:49
从高层抽象来看，HTTP不就是个跨机器边界的执行流（执行状态）转移么。跟仅有两节点的令牌环有区别么？找个能描述这种交互模式的中
文词不就成了。翻译是一码事，能不能推广是另一码事。
假设从今天开始，某人统一用“超文本转移协议”代替“超文本传输协议”来讨论技术问题。然后跟每一个人解释其间的差别，时间开销乘
以解释次数……好吧，不用干活了。
窃以为小狗同学的建议是比较中肯也比较合适的。加个译者注便完了。作者的定义要尊重，译者的译法要尊重，那使用者的习惯不需要尊重
了？
李锟 11:49:50
Tim Berners-Lee是Web之父，W3C的领导者。Roy Fielding是Web架构的主要设计者之一，HTTP 1.1协议专家组负责人，REST架构风格的发明
人，也参与了URI等Web基础协议的设计工作。他们是合作关系。HTTP 1.1因为是属于TCP/IP协议栈中的应用层协议，所以交给了IETF来发布
。W3C与IETF有非常密切的合作。
贾洪峰 11:50:33
Tim Berners-Lee在最早提出HTTP时，用意和roy
贾洪峰 11:50:40
和Roy相同吗？
李锟 11:51:42
那是HTTP 1.0协议，HTTP 1.1协议有非常大的发展。
李锟 11:52:25
URI、HTTP、MIME、HTML，这几个协议是Web的基础架构协议。
贾洪峰 11:53:11
比如HTTP 1.0协议中，transfer就是传输的意思，Roy做1.1时加以扩展或引申，用作转换。有没有这种可能。
009陈睿杰-小狗 11:54:24
看看HTTP被划分到的层次就知道了，属于应用层而非传输层
贾洪峰 11:54:38
HTTP 1.0中呢？
贾洪峰 11:54:51
我完全是门外汉，是请教，不是抬杠呢。:)
李锟 11:55:33
其实如果深入理解REST，尤其是理解了超文本驱动这个概念，就不得不和语义网扯上联系。所以Fielding和Tim Berners-Lee的架构思想完全
是一致的。
009陈睿杰-小狗 11:56:17
1.0也没有任何迹象表名，transfer是传输的意思吧，求证据
郭义 11:56:36
１.２ 什么时候出？
009陈睿杰-小狗 11:56:36
transfer和transport根本就是不一样的
李锟 11:56:37
HTTP 1.1协议中，transfer早就不是传输的意思了。从1999年发布到现在都多少年了？
贾洪峰 11:56:56
现在能不能确定1.0中是什么意思？
009陈睿杰-小狗 11:56:56
从来没有混淆过，不知道你们的论据怎么来的，臆测么？做学问不能这样
贾洪峰 11:57:19
呵呵，我从来也没有论据，我是想知道最初的人为什么会犯这个错误。
李锟 11:57:29
HTTP 1.1协议设计的太成功了，所以IETF认为这方面的工作已经完成，解散了专家组。
郭义 11:57:49
哦。。
009陈睿杰-小狗 11:58:00
transfer那里定义为传输的，非常想找到根源
郭义 11:58:06
那就按 １.１的版本译就ok了。
009陈睿杰-小狗 11:58:30
找到了就豁朗了，直至中文翻译的罪恶根源，呵呵
郭义 11:58:47
这事真不见得事翻译的问题。。
贾洪峰 11:59:02
对，我也是这个意思，看看这个“传输”是彻头彻尾的误译，还是有一些的渊源
郭义 11:59:16
rest 大概０６年 以后开始重提的。。
009陈睿杰-小狗 11:59:38
rails框架的功劳，DHH大神的影响力
李锟 11:59:55
HTTP 1.0中，transfer也不是传输的意思。我可以肯定地告诉诸位。
009陈睿杰-小狗 12:00:11
嗯，我也觉得，transport才是，差别很大的嘛
李锟 12:00:14
transfer和transport的差别，我已经研究过很多年。
郭义 12:00:15
那个时候。。在http 之上 soap协议 大家觉得太笨重了。。。所以http的设计初衷又被重提。。。
李锟 12:01:15
在IETF的RFC中，“transport”（传输）的含义是指：从端到端（例如从ip1:port1到ip2:port2）可靠地搬运比特，也就是TCP/IP协议栈中
的第3层传输层（transport layer）协议所做的那些事情。
李锟 12:01:29
将“transport”翻译为“传输”，100%正确！
郭义 12:01:44
我坚决拥护把翻译搞的精准。。以免误人子弟。。
李锟 12:01:46
而“transfer”的含义是：通过在客户端-服务器端之间转移一些带有操作语义的操作原语，来执行某种操作。“transfer”是TCP/IP协议栈
中的第4层应用层的概念，而不是第3层传输层的概念。“transfer”所转移的是带有明确操作语义的操作原语，而不是没有操作语义的比特
流。
郭义 12:02:52
但是。。http 这事深入的说。。真不是一个简单的翻译问题。。
郭义 12:03:58
rest 之前 。。很少有在应用中把http协议做操作语义来使用。。如果那样译成转移，返回增加了读者理解难度。
李锟 12:04:00
HTTP 1.0和HTTP 1.1最大的区别是什么，我接下来详细解释。
郭义 12:04:33
几遍现在好像也不多。。
李锟 12:05:04
HTTP 1.0基本上就是一个服务器端静态文件的操作协议，并没有抽象的资源概念，HTTP 1.0认为Web服务器上就是一大堆静态文件。
郭义 12:06:46
得建立公正的前提下。。
李锟 12:06:50
HTTP 1.0里面的transfer，就是传递、转移文件。有人把它理解为传输，似乎也可以。但是在协议里面，传输transport其实指的是搬运bit
层次的苦力活。
贾洪峰 12:07:19
如果这样说，那就绝对不是翻译的问题！
009陈睿杰-小狗 12:07:40
还在扣啊
郭义 12:07:44
哈哈。。
郭义 12:07:47
开胃。啊。。
009陈睿杰-小狗 12:07:49
你继续守着这个翻译好了，没人阻拦你
李锟 12:08:18
如何来很好地支持动态内容，是HTTP 1.1协议要解决的一个主要问题。
贾洪峰 12:08:43
文字交流会有这个问题，看不到对方的表情。
郭义 12:09:02
你的意思 弄个茶话会？
贾洪峰 12:09:21
可以请谢老师考虑，哈哈。
郭义 12:09:25
我觉得弄这个比做培训有意思。。。
贾洪峰 12:09:25
不过，我肯定是参加不了的。
李锟 12:09:36
因此就发明了一个新的概念叫做资源，注意：资源和面向对象编程里面的对象类似，是一个抽象的工具。资源不仅仅可以代表服务器端一个
文件、数据库中一条记录这类具体的东西。可以要多抽象有多抽象。
009陈睿杰-小狗 12:09:43
听李老师讲完嘛，你们这帮家伙
郭义 12:09:44
你可代表一方观点啊。
贾洪峰 12:10:12
在这件事上，我没有观点。我只是想理清前后原因。
李锟 12:10:46
有了资源之后，还需要设计一个统一的接口来操作资源。否则每一个资源操作的方式都不一样，那样做会严重降低Web应用的可伸缩性。
郭义 12:12:28
不过插一句。。http是协会搞出东东。。所以。。。会考虑的全面，严谨些。
李锟 12:12:35
统一接口包括的内容很丰富，可以参考我写的博客。
009陈睿杰-小狗 12:13:54
我也插一句，其实，李老师是在普及HTTP知识哟，如果你们看过很早就出版的那本啰嗦至极的《RESTful webservice》，就不会觉得新奇了
：）
郭义 12:14:31
很早看的了。。记忆已经模糊了。
郭义 12:16:31
其实作为一个技术小白来说。。。超文本传输协议。来源大概是为了考虑读者理解来说的。
郭义 12:16:53
我的想法是这样。。。
郭义 12:16:57
tcpip
郭义 12:17:18
tcpiip协议大家说事传输协议。。这个没争论吧。
李锟 12:18:00
别想的那么复杂，第一个翻译HTTP的家伙，没准就是喝了点小酒，凭感觉就直接翻译为“传输协议”了。这和第一个翻译FTP的家伙类似。
郭义 12:18:37
所以。。当时的译者 一定是这样想的。。http协议是其上的应用层，，而且事针对超文本的。。所以叫乘超文本传输协议。。读者理解起
来顺理成章。。。
李锟 12:18:53
HTTP/FTP/NNTP..... 全是应用层协议。transfer是应用层的概念。
李锟 12:19:16
传输这件事情，TCP+UDP已经干的很好了
郭义 12:20:17
是的。。但是 按我刚才说的这么想。。译者当时这么想也说的过去。
009陈睿杰-小狗 12:20:30
应用层是不用关心传输的事儿的
009陈睿杰-小狗 12:21:00
就好比你去邮局寄信，不会去关注邮差的活儿
009陈睿杰-小狗 12:21:18
其实说起来，http还真和邮局很相似
郭义 12:21:45
啊～～
009陈睿杰-小狗 12:21:52
难道你不觉得么
009陈睿杰-小狗 12:21:57
那些header
郭义 12:22:09
我觉得email 协议更想了。。
009陈睿杰-小狗 12:22:39
囧，你看名字就知道了，mail……
贾洪峰 12:23:22
再请教一下，“转移”和“传输”从中文含义上怎么区分呢？
009陈睿杰-小狗 12:26:18
你去寄信，信封上的东西，比如地址、邮编，是有语义的，你可以看作是“应用层”的东西，你通过信件“转移”你的想法给对方；邮局的
派送车，只管帮你运输的，那个是“传输层”的东西，帮你“传输”这封信件。不知道我能不能这么理解
009陈睿杰-小狗 12:27:31
对应到HTTP协议的内容，request header、response header，就是信封上的元信息，body是你的信件内容，就差不多了嘛
009陈睿杰-小狗 12:28:08
http很依赖这些元信息的，它根本不关注整个东西是怎么送达到对方手里的，这有问题么？没有吧
009陈睿杰-小狗 12:28:31
传输有TCP、IP在做了
009陈睿杰-小狗 12:29:07
其实要真正明白区别，就要明白资源的概念
贾洪峰 12:29:09
这是“高级汉语词典”中的解释
009陈睿杰-小狗 12:29:22
资源是抽象的概念，你不可能在网络上真正的交换一个资源实体
009陈睿杰-小狗 12:29:36
你只能操作表述
009陈睿杰-小狗 12:29:44
资源永远无法直接触及
009陈睿杰-小狗 12:30:02
没有仔细看过REST的书，不能理解这其中的差别很正常
009陈睿杰-小狗 12:30:56
在REST架构中，服务器和客户端之间都只能通过资源的表述来进行交流，而非资源本身，这就是为什么要用“转移”来称呼这个操作
009陈睿杰-小狗 12:31:03
转移表述，而非传输资源
009陈睿杰-小狗 12:31:40
不知道我这么说能不能打消你的疑虑，如果不行，只能建议你看看RESTful web service了，那本纯入门
LZSoft·梁涛 12:37:28
对此我有一个简单定义。Transport会有持续存在的副本产生，原本和副本存在于不同的执行环境中。Transfer没有副本产生，原本会完整移
动到接受端执行环境中，发送端环境不予以留存，降低状态不一致的可能性。
009陈睿杰-小狗 12:39:22
太抽象了，你这个比资源本身还抽象，囧
009陈睿杰-小狗 12:39:25
无法理解，哈哈
LZSoft·梁涛 12:46:19
所以说做不了学术。解释不清楚。
LZSoft·梁涛 12:46:41
但是REST要解决的一个问题就是缓存。
LZSoft·梁涛 12:46:56
维护一致性的成本有时高得离谱。
LZSoft·梁涛 12:51:41
小狗，还有一个解释。转移是Ctrl-X Ctrl-V，传输是Ctrl-C Ctrl-V。清楚不？
009陈睿杰-小狗 12:56:35
我觉得不能这样说诶，比如资源，不能说是剪贴到客户端了吧，只能说资源的状态（表述）被传递给客户端了，所以这么一来，cv更合适
LZSoft·梁涛 12:56:56
只是表达一下概念嘛。
009陈睿杰-小狗 12:57:04
不过如果主语是表述，那也可行
LZSoft·梁涛 12:57:52
这样解释的话我想用过Windows的人基本都能理解轮廓了。
009陈睿杰-小狗 12:57:54
HTTP注重了可伸缩性，自然一致性方面就不能两全了，李老师之前说的，谈论一个架构，是要放到特定的上下文环境中的
LZSoft·梁涛 12:57:59
再细讲应该会容易点。
009陈睿杰-小狗 12:58:38
要实现一个完美无缺兼容百家所长的架构，根本不可能
LZSoft·梁涛 12:58:48
所以嘛。
009陈睿杰-小狗 12:58:59
要伸缩，要容错，又要一致，哪里找去哦
LZSoft·梁涛 12:59:05
争论长短连接是不是普适意义不大的。
LZSoft·梁涛 12:59:44
争论长短连接何时何地特适才有意义。
009陈睿杰-小狗 13:00:13
所以我才说，那个可以采用更合适的方案，在项目里面我用node来处理这个了
LZSoft·梁涛 13:01:35
不会有人傻到在嵌入式通信系统上架个REST的。那不适合，就这么简单。
009陈睿杰-小狗 13:09:16
但是对于我这种页面崽儿，不得不关注啊
009陈睿杰-小狗 13:09:26
别人我管不着，自己可是要天天打交道
018图灵谢工 13:15:13
刚才吃饭，和松峰他们也在争论这个问题
009陈睿杰-小狗 13:16:17
不知道能不能讨论出个结论来
018图灵谢工 13:19:08
松峰说转移也不太准确
009陈睿杰-小狗 13:22:46
但是，达成的共识是，传输 是不靠谱的翻译，对不对
LZSoft·梁涛 13:23:19
明显不对。
图钉派007LL 13:31:31
怎么能叫转移呢？
图钉派007LL 13:31:59
叫
邓聪 13:32:20
我感觉吧，讨论的点在，http刚出现端到端的场景了与http后来被用做rest style的架构的场景 被赋予的意义就不同了
LZSoft·梁涛 13:32:49
@邓聪 这是一个分歧点，顶。
贾洪峰 13:32:54
嗯，我与邓聪的感觉一直，但没查到原始文档
图钉派007LL 13:33:09
叫漂移
009陈睿杰-小狗 13:33:13
现在的关键是，在当下这个环境，一定要明确其真正的含义
009陈睿杰-小狗 13:33:41
要不然，HTTP还是会被人误用，搞RPC、SOAP那类
009陈睿杰-小狗 13:34:04
理解这个点，是首要先绝条件
邓聪 13:34:38
看过今天与以往的讨论 李老师对rest研究下了很多功夫
009陈睿杰-小狗 13:34:41
从名字上就给人误导，你还指望他去深入掌握REST么，搞笑
LZSoft·梁涛 13:34:57
举个例子，网游里的连接维持心跳包机制，属于“传输”还是“转移”？
009陈睿杰-小狗 13:35:00
dlee是国内REST架构的先驱
018图灵谢工 13:35:09
移送
邓聪 13:35:14
得 别当权威了
邓聪 13:35:38
所以还是先搞*景 再讨论到底什么翻译吧
009陈睿杰-小狗 13:35:39
姑且不管权威不权威，人家付出的努力你们怎么就看不到
018图灵谢工 13:35:48
反正讨论还是有价值的
邓聪 13:36:05
那篇论文也是2K年出来的 没准现在不同场景下 又发生了变法
018图灵谢工 13:36:14
李松峰
：怎么判断翻译字面化？我有一个经验，就是看翻译在字面上是否可逆。如果中文译文很容易让人联想（或对应）到原文字面，那就是翻译
字面化。当然，对于简单的或特定的翻译，字面化不一定是问题。但如果字面化的情况非常普遍，那翻译肯定有问题。结论是：好译文应该
在字面上不可逆。
009陈睿杰-小狗 13:37:18
上面的上面的上面，REST最近被提起来，恰恰推翻了你的说法
李锟 13:37:36
没什么权威不权威的，韩寒同学早就批判过权威了。首先第一步，不要习惯性地把transfer翻译为“传输”肯定是正确的。尤其是在HTTP这
个专业术语里面。雪丰建议不要翻译为中文，我很赞同。
009陈睿杰-小狗 13:38:00
现在有更多的人回头思考HTTP的起源，以及他的架构思路
邓聪 13:38:27
你是看到结果了，然后按照你的结果去推倒起源吗？
009陈睿杰-小狗 13:38:37
DHH这种顽固分子都这样了
李锟 13:39:01
transfer我建议翻译为转移、传递。有些同学感觉不准确，这是因为汉语在这方面的细腻程度不够。
LZSoft·梁涛 13:39:04
从工程角度去看，一开始有架构定义么？
009陈睿杰-小狗 13:39:25
论文，要看定义请先仔细看过论文，这是讨论的前提！
LZSoft·梁涛 13:40:33
我觉得不从HTTP本身出发，而是从其前身去探究，说不定当时的含义就是在两个端点间传点什么文本罢了。
李锟 13:40:43
transfer和transport的区别，我前面已经详细解释过了。主要区别就是一个有操作语义，一个完全没有操作语义。
邓聪 13:40:50
HTTP权威指南 貌似不是说 REST http的架构
弄个http1.0到http1.1升级后 当下赋予的意义 弄个故事会 倒不错 哈哈哈哈哈
LZSoft·梁涛 13:40:56
只是后来发现这样设计在某些场景下非常适用，于是写Paper规范化。
李锟 13:41:33
思而不学则殆，同学们。争论这么长时间，也不肯自己去读一下协议原文？
邓聪 13:41:51
你怎么知道我们没去看协议原文？
LZSoft·梁涛 13:42:01
读过了。
李锟 13:42:11
找来原文再争论吧，否则老是转圈圈，其实没前进，完全是浪费时间。
009陈睿杰-小狗 13:42:22
我倒是感觉，roy当初参与设计http的时候，心里早就有谱的了，肯定不是后来才发现，咿，我的架构可以干这个诶
LZSoft·梁涛 13:43:32
跟理想主义做斗争的确属于浪费时间。
李锟 13:43:50
找来原文，证实一下你的想法。
李锟 13:44:52
扣帽子也是国人的习惯之一
图钉派007LL 14:02:48
你们讨论后统一了，告诉我答案就好。
009陈睿杰-小狗 14:03:02
打击伸手党
图钉派007LL 14:03:43
讨论无果的话，你们的能力就太差了。
图钉派007LL 14:03:51
以后就别混。
贾洪峰 14:04:03
嘿嘿
李锟 14:04:59
知识背景不一样，争论很难有定论。闻道有先后，术业有专攻而已。
图钉派007LL 14:06:24
闻道有先后，术业有专攻，讨论后无果，专攻也白搭。
009陈睿杰-小狗 14:06:25
别争论了，看看图灵这本书最终怎么处理吧，反正我就那个建议，加译者注说明下
009陈睿杰-小狗 14:06:49
伸手党别掺和了，你也等这书出来好了
李锟 14:07:07
相互妥协的做法就是保留HTTP不要翻译
009陈睿杰-小狗 14:07:53
缩写可以不翻译，但是如果原文是全称怎么处理？
009陈睿杰-小狗 14:08:13
统一都不翻译么，只好如此了
李锟 14:09:02
直接问丁雪峰，他为这个问题也纠结过一段时间
图钉派007LL 14:09:18
当HTTP已经成为烙印，任何名称对它来说都是多余
009陈睿杰-小狗 14:09:48
想起来了，他的那本书里面的确是没有翻译的
图钉派007LL 14:10:39
呃，忘了加问号：“？”
李锟 14:10:49
不过相对来说，Fielding的意见在这个问题上，权重显然要大过所有人。
李锟 14:11:10
如果确实有人是权威的话，那就是HTTP 1.1协议的原创者Fielding。
李锟 14:11:20
非要争论Fielding是不是权威，那就显得有些无聊了。
郭义 14:11:59
牛xx，，还在继续。。。。
图钉派007LL 14:15:31
牛xx，，还在继续。。。。
李锟 14:15:45
对于这个问题，Fielding本人是什么意见呢？请看这里：
http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm
6.5.3 HTTP is not a Transport Protocol
李锟 14:16:29
不过我还是代劳翻译一下：
HTTP is not a Transport Protocol
HTTP并不是一种传输协议
郭义 14:17:07
我觉得吧。。。如果拿*来比喻，，，当初马列的*。。和 我党的*。。一样吗。。
李锟 14:17:43
行了，诡辩我就不参与了。
郭义 14:18:12
哦。。
郭义 14:18:50
老李的观点就是 field的观点。。
图钉派007LL 14:18:51
好吧，HTTP是一种网络协议
郭义 14:20:03
现在的核心问题就是要不要统一到field的观点。。
李锟 14:21:29
你们谁重视过Fielding的观点啊，都比Fielding牛多了。我昨天就完全承认过。
邓聪 14:22:47
都为了把这本书能高质量出版而已 别酱紫了
李锟 14:22:58
如果我想了解孔子的观点，我肯定会自己去直接读《论语》。当然我承认论语不是孔子本人写的，但是总比去读什么《张批论语》、《王批
论语》强吧？
邓聪 14:23:04
话说这本书够厚啊
郭义 14:24:34
http 那本书是谁写的啊。。
018图灵谢工 14:24:51
我在社区文章下面提到了
郭义 14:25:44
可以问下http作者 和 field的意见。。。
李锟 14:27:08
我把Fielding的邮箱给各位同学，各位同学直接和Fielding联系。
郭义 14:27:41
嗯。。http那本书的也给下吧。。
李锟 14:34:26
Fielding有3个邮箱，可以都试一下。我也不清楚他现在是否还常用，不过专家通常不会经常换邮箱的。
fielding@apache.org
fielding@w3.org
fielding@day.com
郭义 14:35:02
我去试试。。不过我英文不好。。中文不知道是否他认识。
郭义 14:35:22
http那本书的作者也是他吗。。
李锟 14:35:46
Fielding不认识，不过他的夫人认识。他的夫人是*人。
李锟 14:36:03
HTTP权威指南，作者不是Fielding
郭义 14:36:04
牛xx。。。那就好办了。。
郭义 14:36:27
HTTP权威指南 也给问下。。毕竟咱们翻译人家的书，，
贾洪峰 14:36:39
嗯，一定问问他，Http 0.9中的那个transfer到底想表达个什么意思
李锟 14:38:10
Email: fielding at (choose one of) gbiv.com, adobe.com, apache.org 这几个邮箱应该可以用
李锟 14:38:44
Fielding现在估计还在Adobe，因为他创办的公司DaySoft前年被Adobe收购了
丁雪丰 15:09:43
呃，去开了个会回来，发现大家又讨论了一堆。《RESTFul WebServices Cookbook中文版》里，我HTTP和Hypertext Transfer Protocl都没
有做翻译，在后者出现时加了个译注，在译者序里，对这个词的翻译的讨论做了点说明。transfer单独出现时，翻译为“转移”。
018图灵谢工 15:10:36
我转告李松峰了
丁雪丰 15:11:02
恩
009陈睿杰-小狗 15:14:47
丁老师这个做法最讨巧了
009陈睿杰-小狗 15:15:19
无懈可击，赞一个，哈哈哈
丁雪丰 15:15:37
是的，我就是讨论了半天，然后不想再折腾了，呵呵。。。
009陈睿杰-小狗 15:15:58
图灵可以效仿
李锟 15:17:07
目标就是避免读者把HTTP协议继续误以为是一种传输协议，这是我们译者和出版社的共同责任。
邓聪 15:19:26
这个方法真心好
贾洪峰 15:22:55
HTTP权威指南的正文中明确指出：HTTP是在应用层，下面的事交给TCP/IP去做
李锟 15:24:00
对，这个理解是正确的，也是Fielding等原创作者的观点。
李锟 15:24:19
但是如果一开始就直接告诉读者，HTTP是超文本传输协议，读者肯定会被搞晕。
009陈睿杰-小狗 15:25:18
被搞成常规翻译了，不好改也无所谓，知道真相就行了，然后加个注释说明，最好学丁老师，统一不去翻译，哈哈
李锟 15:27:44
SOAP的一个决策失误，就是它把HTTP当作传输协议来用。SOAP其实是把HTTP、SMTP都当作传输协议来用，还非常得意。
贾洪峰 15:27:44
我现在想搞清楚的是这个“传输”是纯粹的误译，还是有历史渊源。
李锟 15:28:30
但是现在在互联网上，还有谁在继续沿用SOAP呢？除非一些历史遗留原因，所有面向互联网的Web服务/API全部都转到REST风格了。
009陈睿杰-小狗 15:28:31
这个就不用纠结了吧，除非能找到当初第一个翻译这个名词的人
009陈睿杰-小狗 15:29:01
REST是互联网应用的趋势，但是我个人现在迷惑的还是那个 超媒体驱动
009陈睿杰-小狗 15:29:17
实在是太没有概念了，还需要不断学习研究，囧
贾洪峰 15:29:32
微软的术语翻译还是比较严谨的，他们都一直用“超文本传输协议”这个词，我觉得值得研究一下。
李锟 15:29:44
先实现资源抽象+统一接口，已经可以带来很多好处。超文本驱动可以逐渐去实现。
009陈睿杰-小狗 15:29:59
现在项目中实际应用的，只能算的上理查德森所说的第二级，也就是CRUD风格的
李锟 15:30:23
晕，微软又能怎样呢？微软和IBM就是SOAP/WSDL老式Web服务的创造者。
009陈睿杰-小狗 15:30:24
这个也要怪Rails这个框架，搞个这种限制的实现出来误导大家
李锟 15:31:14
Fielding博士论文第6章，很大程度上就是讲给微软、IBM内部一些傲慢的企业应用集成专家听的，就是创造出SOAP/WSDL这群人的。
李锟 15:32:06
这帮家伙曾经搞出了一大堆笨重的网络协议，现在有很多人用吗？
李锟 15:33:42
其实现在很多传统Web服务/SOA的大牛都转向了支持REST风格，因为他们发现REST能够给SOA带来非常多的价值。
009陈睿杰-小狗 15:34:00
杯具的是现在国内内多所谓的企业应用，还在搞这个，特别是国企，哎
009陈睿杰-小狗 15:34:37
有本讲SOA和REST的书，不知道现在情况怎么样了
郭义 15:35:28
互联网开发 和软件开发 是不是两个领域？
LZSoft·梁涛 15:35:36
哟，大头。
李锟 15:36:10
《SOA with REST》今年9月出版，陈冀康老师已经承诺人民邮电出版社会引进这本书。
009陈睿杰-小狗 15:36:16
这个就是之前讨论的，上下文范畴了
009陈睿杰-小狗 15:36:26
哈哈，陈老师威武
009陈睿杰-小狗 15:36:55
两个风风火火的名词出现在书里面，还是很牛逼的
009陈睿杰-小狗 15:37:00
书名
李锟 15:37:04
一向都是Web开发的技术渗透到企业应用开发领域，反例我确实很少见到。
李锟 15:37:53
REST就是为面向互联网的Web应用量身定制的一种架构风格，不要总是脱离这个运行环境来讨论架构的优劣。
郭义 15:39:06
。。IBM 和 微软 用 soap的优点是什么呢？
图钉派-34徐浩然 15:39:38
稳定
图钉派-34徐浩然 15:39:39
安全
图钉派-34徐浩然 15:39:42
详细
图钉派-34徐浩然 15:39:44
可溯源
图钉派-34徐浩然 15:39:50
至于性能，反正我们有的是钱，对吧
图钉派-34徐浩然 15:39:53
我们没，客户有
郭义 15:40:02
ok。。那就说。 还是有他们的道理的。
LZSoft·梁涛 15:40:22
那些大公司是靠创造技术概念赚钱的。
李锟 15:40:23
SOAP都是历史遗留技术了。如果现在还问，Sun选择EJB有什么好处，根本就不需要回答。
009陈睿杰-小狗 15:40:32
007，首当其冲，我是第一个引起争论的人，哈哈哈
邓聪 15:40:40
一个时段的产物而已，感觉
009陈睿杰-小狗 15:40:42
要不然这事儿估计就不会这样了
李锟 15:40:45
我们主要做Web开发的人来说，SOAP/EJB都是讨厌的东西，我们从来都不会接触到。
郭义 15:41:08
哦。。
邓聪 15:41:09
比较讨厌，繁琐
李锟 15:41:24
其实阿里淘宝这样的大型网站，也几乎没听说哪里还在用SOAP或者EJB
009陈睿杰-小狗 15:41:57
EJB是过街老鼠现在没人质疑了吧，我在想，同样的事情很可能继续发生哦
李锟 15:41:59
是骡子是马拉出来溜溜，这么大的流量，SOAP/EJB很快就死翘翘了。
郭义 15:42:00
soap 和ejb 有必然关系？
009陈睿杰-小狗 15:42:13
囧，你怎么就不懂得举一反三呢
郭义 15:42:28
哈哈。。讨论吗。。
郭义 15:42:46
总得有人 提出质疑，，有人解答嘛。