咖啡館的故事：FTP, RMI , XML-RPC, SOAP, REST一網(wǎng)打盡
周末的咖啡館有點(diǎn)奇怪， 一群人圍著幾個老頭兒在聊天。
“快說說，你們那個時候沒有HTTP, 沒有JavaScript，到底是怎么讓這些機(jī)器上的程序進(jìn)行'交談'的?”
ftp老頭兒滿臉滄桑，喝了一口咖啡，說道：“簡單得很，機(jī)器A通過我，就是ftp， 上傳一個文件到機(jī)器B的指定路徑，然后再讓rexec 去調(diào)用機(jī)器B上的程序，這程序是程序員寫的，可以讀取FTP目錄下的文件，執(zhí)行業(yè)務(wù)邏輯就行了。”
“什么是rexec ? ”
“就是從一臺機(jī)器上遠(yuǎn)程執(zhí)行另外一個機(jī)器的命令嘛!” rexec老頭兒略帶怒氣地說道，自己雖然沒有ftp出名，但是不至于沒人知道吧!
rexec [remote_host] [command]
“切!騙誰呢，根本不可能，怎么會用這么笨的方式!”人群中傳來了表示不屑的聲音。
ftp和rexec相視苦笑，這些程序員不會想到，早些年真有這么做的系統(tǒng)，是真實(shí)的故事。
ftp招呼telnet一起喝咖啡，不再出聲。
RPC
門口傳來一陣喧囂，CORBA和Java RMI風(fēng)風(fēng)火火地走了進(jìn)來。
人群呼啦一下子就圍了上去，拋棄了那三個老頭兒。
只聽見Java RMI說道：“所有的程序本質(zhì)上都是函數(shù)調(diào)用，函數(shù)調(diào)用在一個進(jìn)程內(nèi)是無比自然的事情。 如果是跨越機(jī)器、跨越進(jìn)程呢? 如果一個機(jī)器上的函數(shù)，能調(diào)用另外一個機(jī)器上的函數(shù)，就像調(diào)用本地方法一樣，會是什么樣子? ”
CORBA笑著說：“哈哈， 畫面太美不敢想象。 ”
人群中有人問道：“調(diào)用遠(yuǎn)程方法就像調(diào)用本地方法一樣?怎么可能?”
Java RMI說道：“在概念上其實(shí)極其簡單，無非就是自動生成客戶端代理和服務(wù)器端代理，這兩個代理完成了大量的臟活和累活，比如：網(wǎng)絡(luò)通信，參數(shù)序列化...... ”
CORBA接著說道：“魔法都在這兩個代理當(dāng)中，我們稱之為Stub(客戶端代理)和Skeleton(服務(wù)器端代理)。這個Stub代理提供了和服務(wù)器一模一樣的接口，客戶端程序只要調(diào)用它，它就會把請求發(fā)到服務(wù)器端的Skeleton代理進(jìn)行處理。 所以對于客戶端程序來說，網(wǎng)絡(luò)不可見，就像是調(diào)用本地的方法一樣。”
Java RMI說道：“對，我們把這種方式稱為RPC。”
人群中發(fā)出一片驚嘆聲：“這RPC可真好啊，Stub和Skeleton代碼能自動生成，我們拿到以后，馬上就可以動手編程了，底層什么都不用關(guān)心。 ”
Java RMI說道：“底層可以采用二進(jìn)制的協(xié)議，性能不要太好哦!”
人群中又是一陣歡呼：“太好了!”
那邊的ftp老頭兒警告到：“大家要小心，要注意平臺綁定，你想用Java RMI嗎? 對不起，客戶端和服務(wù)器都得用Java，都得安裝Java虛擬機(jī)， 什么Python, C#， 沒門兒， 連想都不要想。 ”
telnet接著說：“更重要的是客戶端和服務(wù)器緊密綁定，服務(wù)器端的變化，都必須得重新生成Stub和Skeleton 。 ”
沒想到這些老家伙們目光如炬。
“什么? 這也太無理了吧!” 人群呼啦一聲又涌到了三個老頭那里。
只見ftp老頭兒在紙上寫到： 比如說有這么一個接口， 可以根據(jù)用戶ID查找用戶信息。
- public interface UserService extends Remote{
- public User findUser(int id) throws RemoteException;
- }
利用Java RMI的工具，可以生成Stub和Skeleton， 客戶端拿到Stub以后，可以開心地去編程了。
至于UserService的具體實(shí)現(xiàn)代碼，客戶端不用操心。
過了兩天，某個客戶端要求要給這個接口增加一個新的方法：按照名稱來查找用戶。
- public User findUser(String name) throws RemoteException;
那對不起了，需要重新生成新的Stub和Skeleton， 所有的客戶端都會受到影響，即使你根本不需要新的方法。
大家紛紛唉聲嘆氣，這RPC實(shí)在是太煩人了!
有沒有一種辦法，讓服務(wù)器端獨(dú)立變化，而不影響客戶端，或者說盡量不影響客戶端呢?
XML-RPC
后面有個小伙字若有所思，他剛學(xué)會了XML， 他覺得既然XML的描述能力這么強(qiáng)，能不能用XML來描述一個方法調(diào)用和參數(shù)呢?
比如服務(wù)器端有個接口是getUser，需要提供的參數(shù)是用戶ID， 可以這么描述：
然后通過HTTP Post把這個XML發(fā)送到服務(wù)器端，服務(wù)器端進(jìn)行解析，獲取方法名稱和參數(shù)的值，調(diào)用真正的方法，把結(jié)果也以XML形式返回， 客戶端收到以后再解析就可以得到結(jié)果了。
想到此處，他大聲叫道：“別生成什么Stub和Skeleton代理了，直接用HTTP和XML該多好啊。”
人群被他的奇異想法所吸引，呼啦一下又圍了過來。
小伙子畫了一張圖， 展示了這個處理的過程：
有人問道：“返回的數(shù)據(jù)格式可能很復(fù)雜， 怎么表示啊。”
小伙子說：“這正是XML的強(qiáng)項啊，圖中展示的是int型，還可以有double ,boolean ,string 等各種類型，甚至可以定義結(jié)構(gòu)體。”
對XML來說，這樣的結(jié)構(gòu)體就是小菜一碟。
“這樣客戶端和服務(wù)器端就變成松耦合的了，如果服務(wù)器端想添加一個新的接口，客戶端就不用做變化了。我打算把他叫做XML-RPC” 小伙子說道。
“這種辦法真好!” 人群中開始躁動起來，“我們都用XML-RPC吧!”
SOAP
“小伙子，你叫什么名字?” 狂熱的人群中有個人冷靜地問道。
“Dave Winer， 怎么了? ”
“Winner? 嗯，你的名字真不錯，天生贏家啊， 有沒有興趣和我們微軟一起制定一個新的RPC標(biāo)準(zhǔn)?”
“新標(biāo)準(zhǔn)? 我的XML-RPC已經(jīng)很完善了，又簡單又好用。”
“No,No, 還欠缺不少東西，最要命的就是客戶端和服務(wù)器端沒有正式的協(xié)議約定，都是口頭約定，或者文檔約定，對吧?”
Dave Winer點(diǎn)點(diǎn)頭。
“你想想，如果我們把一個服務(wù)器對外提供的接口也用XML精確地描述下來，任何程序，只要讀取這個XML文件，就知道接口的方法名，參數(shù)名，該有多好?”
Dave Winer又點(diǎn)點(diǎn)頭。
“還有啊，你的XML-RPC只支持HTTP， 我們的新標(biāo)準(zhǔn)可以支持任意協(xié)議啊， HTTP, SMTP，TCP，UDP......都可以。”
“我還是覺得HTTP***!”
“想想看，如果我們的新協(xié)議搞成了，所有的B2B的電子商務(wù)系統(tǒng)都可以用這一套協(xié)議來自動通信，多么***的世界! 你仔細(xì)想想，你是想在這個破咖啡館喝一輩子咖啡，還是想和我們微軟一起改變世界?”
一年以后，Dave Winer 新的協(xié)議問世了，不，這其實(shí)是一套協(xié)議：
WSDL ：用于描述一個服務(wù)的接口，參數(shù)......
UDDI ： 實(shí)現(xiàn)服務(wù)的注冊和發(fā)現(xiàn)
SOAP ： 和XML-RPC很像，但是更加規(guī)范，更加正式，更加復(fù)雜......
他們之間的關(guān)系如圖所示：
微軟的.NET戰(zhàn)略適時啟動，Web Service的宣傳鋪天蓋地：你只要用WSDL定義了接口，就可以選擇任何語言來實(shí)現(xiàn)! Java , Python, 甚至C語言都可以，當(dāng)然，我們的Visual Studo, C#和它結(jié)合得更好，歡迎使用。
人們趨之若鶩。
幾年以后
Dave Winer又一次來到了咖啡館，這一次他選擇了一個角落坐下，要了一杯咖啡，靜靜地聽大家聊天。
“你們知道嗎，微軟太坑爹了，那個SOAP實(shí)在是太難用了!”
“沒錯沒錯，羅嗦，羅嗦，太羅嗦了。你看看，我每次發(fā)個SOAP請求得多麻煩：”
- <?xml version="1.0"?>
- <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:m="http://www.example.org">
- <soap:Header>
- </soap:Header>
- <soap:Body>
- <m:GetUser>
- <m:UserID>1001</m:UserID>
- </m:GetUser>
- </soap:Body>
- </soap:Envelope>
“這算什么，返回值也是同樣羅嗦的XML，解析起來實(shí)在是累死了。”
“是啊，如果沒有可視化工具的輔助，簡直是無法使用。”
Dave Winer一邊喝咖啡一邊想，沒辦法，這XML就是這樣，不過我們的SOAP搞得是不是有點(diǎn)過分了?
“我覺得這就是那些大廠商們?yōu)榱速嶅X而搞出的東西，都是為了賣他們的軟件，一點(diǎn)都不實(shí)用!”
“我們還是回歸最簡單的HTTP調(diào)用吧!” 有人提議。
比如想獲取一個用戶的信息，可以調(diào)用這樣的API http://xxx.com/getUser?id=1001
“服務(wù)器端還要返回又臭又長的XML嗎? ”
“不，我們可以用JSON這種數(shù)據(jù)格式，簡潔緊湊，對JavaScript非常友好，處理起來非常方便。”
大家都表示同意。
“大家別激動，如果用這種方式，和原來的XML-RPC本質(zhì)上是一樣的，都是把服務(wù)器端看做是一堆函數(shù)的集合，然后客戶端去調(diào)用他們。Java RMI是通過Stub/Skeleton代理的方式，XML-RPC是通過XML的方式。” 一個叫做羅伊的小伙提醒道。
“那可不咋地，服務(wù)器端不就是一堆函數(shù)嗎?” 有人說道。
“大家轉(zhuǎn)換一下思路，別把他們當(dāng)成函數(shù)，當(dāng)成資源(Resource)， 從動詞轉(zhuǎn)換成名詞試試。”
聽到羅伊這新奇的想法，一群人又圍了上來。
“名詞? 資源? ”
“是啊，比如說用戶,學(xué)生，訂單等等。他們天然可以用uri來表示。”
“有點(diǎn)意思， 那對這些資源怎么操作?”
“HTTP的方法GET,POST, DELETE,PUT，HEAD...... 可以充當(dāng)動詞啊。”羅伊說道。
“我的媽啊，你竟然把HTTP的方法當(dāng)成增刪改查了。”
話雖這么說，可是大家都覺得這種方式挺簡單的，充分利用了HTTP的特性，只要腦子里不要把服務(wù)器端看成函數(shù)，而是當(dāng)作一堆名詞資源就可以了。
“這種方式叫什么名字?”
“RESTful API !”
“這RESTful看起來不錯啊，要不我們試試?”
“試試去!不行的話就找這個羅伊算賬!”
【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉(zhuǎn)載請通過作者微信公眾號coderising獲取授權(quán)】
