REST架構風格的理解（分佈式應用系統的架構演變）

收藏from：http://www.iteye.com/topic/82227

上週末在杭州網俠大會做了關於REST的演講。會後經過一些交流，特別是今天在msn上面和dlee的交流，感覺自己對於REST的理解更深入了一層。 

我們說REST架構風格，從REST具備的內在特徵來說，它包括了這些特徵： 

1、基於HTTP的資源 
2、以HTTP協議去操作 
3、數據和表象分離 

但是如果我們換一個角度，即分佈式應用系統的角度來看，我們會有一些更有意思的結論： 

分佈式應用系統的架構，經歷了好幾代的變遷，我們來簡單回顧一下： 

1、基於CORBA協議的C++中間件時代 
CORBA時代我還在上學，基本上沒有怎麼接觸過Corba編程。曾經有一次我提供EJB培訓的客戶，正在進行傳統Corba架構向EJB2架構遷移，通過和他們的交流，對Corba多了一些瞭解。當時就感嘆，和EJB2相比，Corba實在太難用了。Corba時代在1998年EJB1.0發佈以後，就逐漸淡出歷史舞臺了。 

2、基於RMI/IIOP協議的EJB時代 
這個時代開始於1998年，到現在基本上已經劃上了句號。其實在EJB出現以前，在1996年Microsoft發佈WindowsNT4.0以後，Microsoft當時也提出了自己的分佈式架構，即MTS，但是MTS的光輝被隨後出現的偉大的EJB技術徹底擊敗，此後，就拉開了Java的應用服務器時代，BEA也是在這個時代的轉折點成長起來的。 

不管是Corba，還是EJB，都有一些共同點： 
1) 通過專有的網絡協議通訊 
2) 不能跨平臺調用 
3) 通過分佈式對象調用來實現分佈式架構，換句話來說就是，分佈式架構是綁定在面向對象的機制上的 

分佈式對象架構的缺陷在EJB2時代被充分暴露了出來，乃至於Martin Folwer在《企業應用架構模式》當中強調，分佈式調用的第一原則就是不要分佈式。更多關於EJB2分佈式對象架構的缺陷在Rod Johnson的《J2EE without EJB》當中被剖析的更加清楚。 

3、基於SOAP協議的Web Services時代 
這個時代始於2001年Microsoft公司推出dotnet平臺，整個行業開始鼓吹Web Services。中間經歷了一次低潮之後，在IBM,BEA成功的聯手炒作SOA之後，再次王者歸來。 

web services有一些明顯不同於Corba和EJB分佈式對象架構的特徵： 
1) 通過標準SOAP協議通訊，一般走HTTP通道 
2) 能夠跨平臺調用 
3) 通訊格式是xml文本，而不是二進制數據格式 
4) 通過RPC機制來實現分佈式調用，而不是通過面向對象機制實現分佈式調用 

web services的優點和缺點都非常突出，這個不是本文的要點，不做具體分析。這裏唯一要強調的是SOAP協議並不依賴於HTTP。事實上SOAP協議可以走很多底層協議，例如SMTP協議，Jabber協議等等。 

REST也是一種分佈式系統的架構風格，那麼REST和上面這些分佈式架構有哪些明顯的區別呢？ 
1) REST走的是HTTP協議，並且充分利用或者說極端依賴HTTP協議 
Corba和EJB是採用專有的二進制協議，SOAP可以但不依賴HTTP，並且僅僅使用HTTP POST。 
2) REST是基於HTTP抽象資源的分佈式調用，換句話來說，就是分佈式調用是綁定在資源的操作上面的。 

通過上面的總結，我們可以做一個直觀的對比表格： 

 

分佈式架構       協議             調用方式
-------------------------------------------------------
Corba架構        專有二進制協議      對象的CRUD操作
EJB架構          專有二進制協議      對象的CRUD操作
Web Services     SOAP協議            RPC方式
REST             HTTP協議            對資源的CRUD操作
--------------------------------------------------------

REST最大的特點是什麼呢？REST是爲通過HTTP協議來進行分佈式調用量身定造的架構 

傳統上，我們開發一個非分佈式的軟件系統，使用OO進行建模和架構，無往而不利。但是分佈式對象卻顯得不那麼有效。對於跨進程的調用，也許我們需要探索更好的面向對象的分佈式調用架構。 

REST是專門爲分佈式調用設計的架構，在REST裏面，分佈式是通過對資源的操作來實現的，不是像EJB那樣通過對象的方法調用來實現的。資源是一種抽象的概念，資源被映射到相應的一套URL規則上面了。所以資源只和URL相關，而與具體實現無關，因此REST具有更好的解藕性。在RoR的實現當中，你可以把一些資源直接映射到model對象上面去，也可以不映射到model上面，而完全是由業務邏輯組合的抽象資源。