讨论参与者共7位:

贾洪峰 图钉派_007_LL 陈睿杰 图灵谢工 曾少宁 温谦 邓聪

这次讨论没有明显的正方、反方,经过连续三天的讨论,大家的意见逐渐统一起来了。

5月23日讨论内容:

贾洪峰 06:17:37 李锟老师,您说的“状态转移”是指state transfer,指一个应用程序的状态(也就是一个页)传送给用户端。 “状态迁移”是state transition, 指状态A变为状态B。

我这样理解您昨晚21:55所说的内容,对吧?!

图钉派_007_LL 06:48:02 transfer,transfer,transfer, 我要天天transfer,transfer,transfer

贾洪峰 06:48:47 哈哈,等这个问题聊透之后,就赶紧换个词,Money如何?

009陈睿杰-小狗 09:05:46 state transfer,说的是资源(resource)的状态转移,是通过资源的表述来进行的;state transition,指的是应用“application”状态,它由一系列互相配合的资源状态组合而成,是一个整体层面的东西,所以可以从一个状态迁移到另一个状态

009陈睿杰-小狗 09:06:42 要真正理解这些个差别,需要去深入学习REST的相关著作,或许光这么讲是说不清楚的,另外,还有个更迷糊的会话“session”状态呢

贾洪峰 09:10:01 State Transfer是把状态由一处传至另一处。那用“状态转移”就会有歧义。“状态转移”的感觉是状态A变成状态B,也就是transition的意思。

009陈睿杰-小狗 09:10:13 那是迁移

009陈睿杰-小狗 09:10:18 而不是转移

009陈睿杰-小狗 09:10:55 转移资源状态,迁移应用状态

贾洪峰 09:11:04 所以我明白你和李老师的意思了。但您到Google上查一下“状态转移”这个词,就可以看到哪种解释比较多了。

009陈睿杰-小狗 09:11:07 这个说法是REST架构理论提出来的

贾洪峰 09:11:34 就是说,初接触“状态转移”的人,一般会想到transition,而不是transfer。

009陈睿杰-小狗 09:16:28 transition我总觉得应该翻译成转换,或者迁移

贾洪峰 09:17:55 状态转移概率,状态转移矩阵 马尔可夫状态转移 ,等等,都是由一个状态变为另一个状态的意思。

009陈睿杰-小狗 09:19:14 转移这个词,字面上没有变换的意思吧?总感觉这里有问题

009陈睿杰-小狗 09:19:45 其实之前我跟李老师讨论过,转移和迁移之间的差异

009陈睿杰-小狗 09:19:56 因为最开始我以为transfer可以翻译成迁移

009陈睿杰-小狗 09:20:07 但是后来通过讨论,区别就在这里

贾洪峰 09:21:15 我非常不喜欢外企的人在说话时中英文掺杂,但在讨论技术时,有时还真的说出英文原文才不致误会。:)

009陈睿杰-小狗 09:22:57 所以不用纠结了,反正就那样了

贾洪峰 09:23:33 对,道可道 非常道。说出来的道,就已经不是那个道了。哈哈

009陈睿杰-小狗 09:32:59 真的假的,怎么是这本书

009陈睿杰-小狗 09:33:14 为何不是the rspec book??

李锟 09:36:16 贾洪峰2012-05-24 09:17:55 状态转移概率,状态转移矩阵 马尔可夫状态转移 ,等等,都是由一个状态变为另一个状态的意思。

不过在Fielding论文里面,transfer和transition是分开用的,不是一个意思。transfer的含义就是通过转移、交换有操作语义的原语,对服务器端的资源执行某种操作。

贾洪峰 09:37:03 我明白!

我是说REST中的state transfer译为状态转移的话,就容易和状态转移矩阵中的“转移”相混淆

贾洪峰 09:37:36 Fielding论文中的 State transfer是从一处传至另一处,Transition是从一个状态变为另一状态,对吧?!

009陈睿杰-小狗 09:37:44 别纠结了,保留原文即可,嘿嘿

009陈睿杰-小狗 09:37:52 不用翻译了

贾洪峰 09:38:28 呵呵,李老师在给我讲这个论文呢。如果不是这两天的讨论,我哪里会去看Http 1.1的原文和Fielding的论文。:)

李锟 09:38:32 transfer的是资源的表述。资源表述的本质是什么呢?代表了资源当前时刻的状态。

贾洪峰 09:39:23 就相当于把资源当前时刻的状态表达 由一处传到另一处,对吗?

009陈睿杰-小狗 09:39:36 想成快照就行了,没有状态变化的意思

009陈睿杰-小狗 09:39:51 FSM里面的那个状态,是要变化的

李锟 09:39:53 客户端通过GET请求,得到某个URI标识的资源的当前时刻状态。然后对其做一些改动,再通过POST请求将改动后的表述发到服务器端,修改资源的状态。

贾洪峰 09:39:58 transition没有状态变化的意思?

李锟 09:40:22 GET请求得到的,是资源的表述,而不是资源本身;POST请求发送到服务器端的,也是资源的表述。

009陈睿杰-小狗 09:40:29 至少REST上下文环境中,是没有变化的,表述

李锟 09:40:51 要注意GET/POST/PUT/DELETE这四种请求的用法

009陈睿杰-小狗 09:41:21 李老师,rails社区前一阵子讨论说要多加个PATCH

009陈睿杰-小狗 09:41:45 按道理,rails里面,现在PUT对应的update操作,很多只是部分更新

009陈睿杰-小狗 09:42:06 所以使用PATCH的确更合适点,只是不知都这个请求方法是不是广泛被使用了?

李锟 09:42:07 GET是安全的、幂等的。绝对不能改变资源可观察到的状态,而且可以发多次。发一次、两次、三次、五次、十次得到的应该是一样的资源表述。当前前提是发十次请求的过程中,资源状态不能被其他请求修改。

贾洪峰 09:43:03 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.

009陈睿杰-小狗 09:43:37 这里人家说的是应用状态的迁移了

009陈睿杰-小狗 09:43:41 你没看错的

李锟 09:43:49 POST是不安全的、不幂等的,用来对资源的状态做增量式的修改。例如某个资源代表一个计数值,当前值为1,我想把它改成7,POST请求只能用增量的方式来修改,例如一次+2,发送3次;或者一次+3,发送两次。

009陈睿杰-小狗 09:43:50 state of the application

009陈睿杰-小狗 09:43:58 你没有仔细看我一开始的发言

009陈睿杰-小狗 09:44:23 超媒体驱动,就是这样来的

李锟 09:44:59 发送一次POST请求和发送两次、三次、五次、十次POST请求的结果不一样,有累积效应。所以浏览器在刷新由POST请求获得的页面时,都会问用户是否要这样做。

贾洪峰 09:44:59 state transitions 我是想确认,这里是不是状态变化。当然,状态A 受到激励后还是状态A,那也算一个“变化”

009陈睿杰-小狗 09:44:59 在REST的范畴,你必须要区分几种不同的state,这是前提

009陈睿杰-小狗 09:45:17 所以李老师说这里的transitions是 迁移

009陈睿杰-小狗 09:45:29 我比较赞同这种翻译

009陈睿杰-小狗 09:45:54 之前我还误认为REST里面那个T是迁移呢,绝对是大错特错

李锟 09:46:07 PUT请求是不安全的、幂等的。也是用来修改资源的状态,但是是一次性的,不是增量式的。

邓聪 09:46:27 我总是感觉,讲HTTP时候,为嘛总是吧REST设计理念参合进来,难道这是必须的?

贾洪峰 09:46:32 最后一步是发生了“状态转移”,是吗?

009陈睿杰-小狗 09:46:33 李老师,PUT有没有要求,必须是replace?

贾洪峰 09:47:27 REST中的T,是将the next page传送给用户

009陈睿杰-小狗 09:47:42 比方说rails里面,我put修改一个资源,但是只提供了一部分的字段,在DHH看来,好像不太对劲,他说这种是patch,put必须传递所有字段

李锟 09:47:46 还以刚才那个计数值资源来举例,要把它从1改到7,直接发一个PUT请求,相当于一次赋值操作。赋值1次,最后值是7,赋值2次、3次、5次、10次,最后值还是7。所以是幂等的,可以发任意多次。

贾洪峰 09:47:47 也就是把application的下一个传送给用户。

贾洪峰 09:48:25 @邓聪,李老师认为HTTP和REST中的Transfer是同一个意思,所以应当放在一起综合考虑。

李锟 09:48:36 DELETE请求是不安全的、幂等的。发一次、两次、五次、十次DELETE请求,结果都是URI所标识的这个资源被删除。

李锟 09:49:34 现在还有很多人滥用GET请求来执行修改、删除操作,这样做是很不安全的。

贾洪峰 09:49:57 大家可以看看有限状态机的名词:状态转移 应当指的就是这里所物的transition

贾洪峰 09:50:08 所说

009陈睿杰-小狗 09:50:47 不用太纠结了,在具体的上下文环境来考虑名词的翻译,比较合适

009陈睿杰-小狗 09:50:54 较真的话永远都扯不清

009陈睿杰-小狗 09:51:12 明确含义才是最重要的

009陈睿杰-小狗 09:51:27 李老师,你还没有回答我的问题哦

009陈睿杰-小狗 09:51:39 rails社区提出来的pacth做局部更新,您怎么看

贾洪峰 09:51:45 因为Fielding的论文中恰好把REST与虚拟状态机进行了类比。

贾洪峰 09:52:01 我搞清内涵了。哈哈。谢谢

009陈睿杰-小狗 09:52:29 他说的那个是将超媒体作为驱动应用状态的引擎

009陈睿杰-小狗 09:52:46 所以你必须要区分不同的state,要不然你搞不清楚的

009陈睿杰-小狗 09:53:20 resource state、application state、session state是不同的东西

009陈睿杰-小狗 09:53:46 你这里类比的FSM,其实应该是说的application state

009陈睿杰-小狗 09:53:52 而非resource state

009陈睿杰-小狗 09:54:28 光讨论没用,先去看看REST的书就知道了,包括RESTful webservice以及REST实战,两本书都有讲

贾洪峰 09:54:53 那您说REST中的state是谁的State?

009陈睿杰-小狗 09:54:55 但是这两本书对会话状态的讲解,貌似是有冲突的,两个作者说的不是一个东西

009陈睿杰-小狗 09:55:00 resource state

009陈睿杰-小狗 09:55:13 哦,你说REST?是都讨论了

贾洪峰 09:55:34 REST中的S指的是谁的State?

009陈睿杰-小狗 09:55:54 我觉得是resource

贾洪峰 09:56:08 那您看这一句话: 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.

贾洪峰 09:56:25 这是前面那一句的完整句子!

李锟 09:57:03 要注意的是“transfer protocol”绝对是一个有特定含义的专业术语,这是国内绝大多数译者从来没注意到的问题。

009陈睿杰-小狗 09:57:09 这个就是最著名的 超媒体驱动 的说法了,在application state的上下文,的确是这样的

李锟 09:57:33 IETF的那些“transfer protocol”协议,都不是传输协议

李锟 09:58:11 “transport protocol”和“transfer protocol”两个术语,一定要仔细分清楚。

李锟 10:01:27 Hypertext transfer protocol - HTTP File transfer protocol - FTP Simple Mail Transfer Protocol - SMTP Network News Transport Protocol - NNTP 如果这些全部都是传输协议,那就太搞笑了

李锟 10:02:17 我只提HTTP,不提其他几个,就是害怕翻案规模太大,板砖会太多。

009陈睿杰-小狗 10:02:46 反正REST的书里面,对各种状态都有讲解,针对资源状态,肯定是transfer“转移”操作,对于应用状态的变化,就是transitions,翻译成迁移也好什么也好。注意看你发的那段英文,他说用户通过选择表述中的不同链接来推动应用状态的转变(迁移),然后应用到了另一个状态(the next pate),它的表述(representing the next state of the application)会被 转移(transferred )到客户端

009陈睿杰-小狗 10:03:15 所以你贴的引用,恰恰给我们的说法提供了证据

009陈睿杰-小狗 10:03:16 so,别争论了

李锟 10:04:25 不对,应该是Network News Transfer Protocol ,也不是传输协议,是我刚才笔误。请看:http://tools.ietf.org/html/rfc3977

018图灵谢工 10:04:42 还在讨论拉

009陈睿杰-小狗 10:04:48 必须要明确不同的state,才能知道REST在说什么

李锟 10:04:51 应用层绝对不可能出现很多传输协议,全部都是transfer protocol

009陈睿杰-小狗 10:04:56 这是我个人的建议,先去看看书

李锟 10:05:31 谢老师,现在翻案规模大了。FTP、SMTP、NNTP的中文翻译全部需要翻案。

009陈睿杰-小狗 10:05:37 哈哈哈哈

李锟 10:05:55 板砖横飞的景象很快就会出现

贾洪峰 10:06:40 呵呵

曾少宁 10:09:34 其实像是译者们的想法,要不要考虑一下对读者的影响?

009陈睿杰-小狗 10:10:05 就是因为怕影响不好才讨论这个问题的了

009陈睿杰-小狗 10:10:12 很多人都不知道HTTP的真正含义

009陈睿杰-小狗 10:10:19 光看那个字面翻译的话,你说是不是

曾少宁 10:13:24 可不可以这样想,专门研究协议的读者搞懂的概率是不是大一些;而不需要研究协议的,不要强迫他们把听了这么多年的叫法强行转过来?或者,查资料时总出现两种概念。混乱啊

曾少宁 10:13:56 如,做浏览器的,和开发Web应用的

曾少宁 10:14:31

——我是路过的,可能扯远了,见谅,呵呵

贾洪峰 10:14:47 这样吧,谁的微博粉丝多?搞个调查,要求大家不查资料,凭感觉选一下HTTP属于哪个层。:)

009陈睿杰-小狗 10:14:49 现在就是对概念的理解正确与否,会影响到实际开发了

李锟 10:15:08 图灵可以做到的第一步,也是比较容易被大多数人接受的做法,就是保留这些协议的缩写词不翻译。不再直接不加思索翻译为xxx传输协议。

009陈睿杰-小狗 10:15:14 不懂的人,就倾向去搞RPC、SOAP那一套

018图灵谢工 10:15:26 你们写,我来转发

曾少宁 10:15:29 对啊!不译最好

009陈睿杰-小狗 10:15:35 我也建议不要翻译

李锟 10:15:39 这一步其实已经是非常大的进步了,做出这一步之后,再考虑以后如何做。

李锟 10:16:23 HTTP、FTP、SMTP、NNTP,遇到这些应用层的xxx transfer protocol都不要翻译为传输协议。

009陈睿杰-小狗 10:16:31 HTTP对web开发人员来说是非常重要的,不要在误解乱用了,书也不要成为帮凶

曾少宁 10:18:05 不过,这样讨论真是挺好,现在我也想看这书了

009陈睿杰-小狗 10:18:12 李老师,你要回答我的问题啊

009陈睿杰-小狗 10:18:28 patch这个http方法有必要提出来作为统一接口的一部分么

009陈睿杰-小狗 10:18:46 因为现有的所有书里面,都没怎么提这个方法

009陈睿杰-小狗 10:19:03 但是rails社区里面决定,4.0把patch映射到update诶

李锟 10:20:27 统一接口包括这些方法:GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS 七个方法,其他HTTP方法不是

009陈睿杰-小狗 10:20:42 不过严格按照REST的说法,只要遵循一系列的约束,也无所谓的,我只是想知道rails这种做法到底有什么意义

李锟 10:21:06 不是所有HTTP协议的method都属于统一接口,区别在于这个method是否是用来操作资源的

009陈睿杰-小狗 10:21:16 DHH的理由是,PUT要用完整的表述去更新现有资源

009陈睿杰-小狗 10:22:16 但是现在大家的用法是,update_attributes的时候只是更新了部分attributes,所以他要用PATCH,说这个才是最合适这种情况的,偏执狂啊,反正下个版本,又要按照他的想法来用了

李锟 10:22:38 比如CONNECT这个method,就不属于统一接口。CONNECT是干嘛用的,它是用来将HTTP协议作为一个其他协议的传输通道。

018图灵谢工 10:23:25 李老师,这些内容麻烦还要整理出来,加到你那篇社区文章中,很有价值

009陈睿杰-小狗 10:23:33 那这么说,其实不用纠结DHH说的这个,按照老方法去做api就行了?反正他保证,原来的PUT还是会被正确的路由到update的

009陈睿杰-小狗 10:23:42 我还是不用纠结了

李锟 10:23:51 因为HTTP协议本身其实也支持作为其他协议的传输通道,从这个意义上来说也可以作为传输协议,但是这不是HTTP的主要用途,也是低效的用法。除非想要穿越防火墙,防火墙常常只允许80端口数据通过。

009陈睿杰-小狗 10:24:13 基于HTTP的SOAP不就是这样干的么

贾洪峰 10:24:40 谢老师,您看一下我的微博,没有@您,怕您转发后都是@

贾洪峰 10:24:45 都是@您自己的。:)

李锟 10:24:53 SOAP不是这样做的,早期的SOAP/WSDL只使用POST请求,而且只有一个URI

009陈睿杰-小狗 10:24:59 李老师的weibo多少,我都不知道

009陈睿杰-小狗 10:26:06 好像现在也这样,反正这边电网内部系统的ws,都是POST到一个地址的

李锟 10:26:40 DHH对于REST的理解,还没有到超文本驱动这个层次。不过作为支持REST的开发框架,支持到CRUD式服务基本上足够了,实现超文本驱动的API是应用架构师的职责范围。

009陈睿杰-小狗 10:27:25 Rails的约束太多了,只适合懒人照葫芦画瓢的

009陈睿杰-小狗 10:27:40 我现在恨不得自己去处理http请求,自己来做路由

李锟 10:27:46 SOAP使用POST请求,但是根本没使用HTTP那些标准的header。在HTTP信封中又套了一层自己的信封,而且是放在HTTP body中。

009陈睿杰-小狗 10:28:48 所以说他拿HTTP当传输协议用,就是这个意思了吧

009陈睿杰-小狗 10:29:57 认为HTTP没有语义,不使用标准头,拿来当搬运工用

李锟 10:30:14 HTTP 请求中的method、URI、header代表了人类语言中的谓语、宾语和定语

009陈睿杰-小狗 10:30:50 所以SOAP

李锟 10:31:16 嗨,请告诉我编号123的这本书里面讲了些啥。请用html格式发给我。

009陈睿杰-小狗 10:31:27 还可以基于其他的协议来实现,比如Socket

李锟 10:32:37 如果语义不能由method、URI、header完全表达,而必须要去解析body才能搞清楚。实现大规模分布式缓存就很困难了。

温谦 11:11:21 请问无论是转移还是传输,转移的到底是什么东西?

温谦 11:11:29 我一直没明白

009陈睿杰-小狗 11:11:41 资源的表述信息

009陈睿杰-小狗 11:12:10 资源是抽象的概念,只有表述可以被服务器端和客户端操作

009陈睿杰-小狗 11:12:51 比如一篇论文,就可以是个资源,他的表述可以是各种格式的东西,比如markdown格式的、html格式的、pdf格式的

温谦 11:13:05 不是 HyperText ?

009陈睿杰-小狗 11:13:11 甚至是mp3音频录音

温谦 11:13:27 哦,是,就是一堆东西?

009陈睿杰-小狗 11:13:30 这些具体的表述才能被操作、转移

李锟 11:13:36 HTTP、FTP、SMTP、NNTP中的transfer说的都是转移具有语义的操作原语,来操作服务器端的某个资源

009陈睿杰-小狗 11:13:38 对,因为资源是抽象的概念

009陈睿杰-小狗 11:14:06 你不可能直接操作资源的,只能通过表述

李锟 11:14:08 操作原语这个词,如果熟悉电信协议的同学会见到过

温谦 11:14:37 OK,那我们说把一本书从北京转移到上海,和把一本书运输到上海,区别有多大呢?

李锟 11:14:44 在客户端、服务器端之间转移/交换这些操作原语

李锟 11:14:57 区别在于是否具有操作语义

009陈睿杰-小狗 11:15:22 首先,你要明确你的意图,你是想把书的内容给上海的人,你不会关心运输过程

李锟 11:15:36 运输是没有操作语义的,transport做的就是可靠地实现端到端的比特搬运。

温谦 11:16:20 如果单就词语来说,转移本来也没有吧,也是后来加上去的。

009陈睿杰-小狗 11:16:48 然后,你可以通过各种途径把书的内容传播到上海,比如,你可以给扫描件,这时候扫描电子版就成了这书的一个表述

009陈睿杰-小狗 11:17:21 不过以这种类比来描述HTTP的操作过程感觉不是很合适的

温谦 11:17:29 把一本书扫描仪后传到上海,我感觉如果不能叫再运输,那么也同样不能叫转移。

009陈睿杰-小狗 11:17:54 所以这种情况不好类比到http的

温谦 11:18:09 我的意思是,传输还是转移,附件的含义都是后来被人为赋予的。

温谦 11:18:17 从汉语来说没什么意义。

009陈睿杰-小狗 11:18:29 因为必须要明确其中的区别才行的

李锟 11:18:30 要从客户-服务器的角度来思考问题,transfer的目的是操作服务器端的某个资源

温谦 11:18:32 附加的含义。

009陈睿杰-小狗 11:18:53 要不然,就会出现把HTTP当搬运工用,而忽略了协议本身的一些东西,比如,请求头

009陈睿杰-小狗 11:18:57 还有method

温谦 11:19:20 这些东西不会因为叫作传输还是转移而别换。

温谦 11:19:28 变化。

009陈睿杰-小狗 11:19:34 我觉得是有很大影响的

温谦 11:19:47 懂得人叫什么都懂,不懂的人交什么都不懂。

009陈睿杰-小狗 11:19:48 如果你知道http本身就不该用来简单搬运bit,也就是传输

温谦 11:19:59 这些东西本来就是汉语里本来没有的东西。

009陈睿杰-小狗 11:20:09 你就会去考究http的基础设施,比如header、mime type

009陈睿杰-小狗 11:20:32 现在有多少web开发人员重视这个了?在rest被重提之前,恐怕没有多少人在实际开发中遵循了

009陈睿杰-小狗 11:20:38 利用了这些设施

009陈睿杰-小狗 11:21:04 当你明确了那个词的真正含义了,才能明白为啥要有这些基础设施

温谦 11:21:05 我觉得没那么严重吧,这点事儿有那么复杂吗~~

009陈睿杰-小狗 11:21:13 目前的状况就是这样的

009陈睿杰-小狗 11:21:36 有多少人运用了http的mime type?按照语义使用请求方法的?

温谦 11:22:00 明确一个词的含义,和把这个含义赋予给那个词,没有必然的联系,特别是你要赋予的那个词本来就没什么相关的基因的时候。

009陈睿杰-小狗 11:22:13 你都认为是搬运工了,自然不会去研究这些附加语义的东西,http不就是传输数据的么,干嘛还要这么用

温谦 11:22:48 再说了,当初HTTP出来的时候,也没有那么复杂吧,无非就是取一些文件而已。

009陈睿杰-小狗 11:22:50 就问一句,在rest没重提之前,有多少web开发人员重视过http协议本身

009陈睿杰-小狗 11:23:18 很多开发人员,就只知道get和post

009陈睿杰-小狗 11:24:03 也够直接的,取数据get,发数据post,果然是简单明了,但是实际上真的是这样么

李锟 11:24:05 “transfer protocol”和“transport protocol”的区别,可不是最近才突然出现的。早在20年前的协议中就存在,但是国内的译者从来都没注意。

温谦 11:24:21 呵呵,即使如此。 还是那个例子,现在很多大学里的黑板都是绿颜色的,难道都要改叫绿板?

李锟 11:24:28 这个区别很重要,我们讨论了好几天就是为了澄清这个问题。

009陈睿杰-小狗 11:24:42 算了,我不打算继续争论下去了

009陈睿杰-小狗 11:24:46 反正该说的都说了

009陈睿杰-小狗 11:24:48 爱咋咋地

009陈睿杰-小狗 11:25:20 只怕HTTP tdg这本书出了,也不会有多少人去深入学习,那就搞笑了

温谦 11:26:52 我不懂,随便说说而已,呵呵,我是嫌麻烦的人。

李锟 11:27:00 http://www.ietf.org/rfc/rfc0821.txt 看看SMTP协议是什么年代发布的,August 1982。都30年了,那个时候IETF就明确写成“transfer protocol”,而不是“transport protocol”

李锟 11:27:41 同学们,三十年时间,国内的译者都没注意到“transfer protocol”和“transport protocol”其实说的不是一件事情。这说明了什么?

018图灵谢工 11:28:18 说明很不重视

009陈睿杰-小狗 11:28:24 也不怪了,看看HTTP被程序员怎么用的就知道了

018图灵谢工 11:28:26 很不专业

温谦 11:28:57 恩,很多事情都需要在现实和理想中选择,加油!

009陈睿杰-小狗 11:29:00 打心里就觉得是一简单的玩意儿,就那样了,还需要你出书么,所以http tdg这么多年都没被引进

009陈睿杰-小狗 11:29:16 侧面也说明了这个问题

009陈睿杰-小狗 11:29:25 02年的书了啊,现在才出中文版

贾洪峰 11:35:58 目前有13个投票,10个选应用层,2个选会话层,1个选Transport层。:)

贾洪峰 11:37:00 呵呵,我搞错了,应当设定多选题,有一位朋友说占了三层。

009陈睿杰-小狗 11:37:12 哈哈哈哈

邓聪 11:48:05 其实人人都知道在应用层,就是REST一来,赋予的意义升级而已

邓聪 11:48:28 也就是多都知道那么一回事,而能词语的意义有误差

邓聪 11:48:33 可能

009陈睿杰-小狗 11:49:29 反正名词真的不重要,重要的是理解含义,然后正确运用,现在的情况就是误用的太多了

009陈睿杰-小狗 11:49:59 其实遵循REST的约束,不是复杂了,而是简化了很多东西

温谦 11:59:05 严格说,transfer 翻译成转移也是不严格。在英文中 transfer:transport 和汉语中的 转移:传输 并不对等。

温谦 11:59:29 在英语中二者的差异大于中文中二者的差异。

温谦 12:00:29 英语中transfer的特征是物主的改变,在汉语里转移似乎并没有这么强的这个特征。

009陈睿杰-小狗 12:00:58 移交 怎么样,哈哈

图钉派_007_LL 13:29:32 transfer,transfer,transfer,我们transfer

009陈睿杰-小狗 13:29:56 你们疯了