關於HTTP中文翻譯的討論之二

討論參與者共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 你們瘋了