目前基於網絡應用的架構風格主要有三種:瀏覽器
RPC架構風格 將服務器看做是由一些過程組成,客戶端調用這些過程來執行特定的任務。SOAP就是RPC風格的一種架構。過程是動詞性的(作某件事),所以RPC建模是以動詞爲中心的。緩存
分佈式對象架構風格 認爲服務器是由一些對象和對象上的方法組成,客戶端經過調用這些對象上的方法來執行特定的任務。而且客戶端調用這些對象上的方法應該就像是調用本地對象上的方法同樣,這樣開發就能夠徹底按照統一的面向對象方法來作。可是很惋惜,這樣的抽象並非頗有效,由於分佈式對象與本地對象存在着巨大的本質差異,想要掩蓋這些差異不少時候甚至是有害無益的。服務器
REST架構風格 將服務器抽象爲一組離散資源的集合。資源是一個抽象的概念,而不是表明某個具體的東西。注意:要真正理解REST,就必定要加強本身的抽象思惟能力,充分理解到資源是抽象的。資源是名詞性的,所以REST建模是以名詞爲中心的。網絡
上述是目前基於網絡的應用的主要的三種抽象方式。這三種不一樣的抽象方式會嚴重影響客戶端與服務器的交互模式,而不一樣交互模式的交互效率差異至關大。分佈式對象的交互模式不少時候效率很低,由於掩蓋了分佈式對象與本地對象的差異,不少時候都會致使細粒度的API。實踐已經證實,與RPC和分佈式對象相比,REST是一種對於服務器更加有效的抽象方式,將會帶來粒度更大和更有效率的交互模式。這樣的效果與Fielding設計REST的初衷是吻合的,REST就是專門爲交互的性能和可伸縮性進行過優化的一種架構風格。而SOAP在設計的時候優先考慮的歷來不是性能和可伸縮性,而是互操做性,其開發效率比較低。架構
REST的主要優點其實在於它是一種對於服務器的更加有效的抽象方式。分佈式
性能分析:與基於二進制通訊的RPC例如RMI對比,REST是基於文本傳輸的,從這點看應該說性能不如前者,可是REST強調通訊語義對於中間組件的可見性,這樣能夠改善性能和可伸縮性。例如瀏覽器就是一種中間件。瀏覽器能夠根據通訊的語義來肯定數據有沒有發生改變,從而進行有效的緩存。RMI傳輸數據再有效,它的數據也沒法作有效的緩存。所以RMI的性能未必比REST好,何況不能緩存會帶來嚴重的可伸縮性問題。性能