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