RPC架構與REST架構
RPC：RPC將服務器看作一些列動作的集合(需要做某件事)
REST：將服務器看作分布式對象集合，客戶端通過調用這些對象上的方法來執行特定的任務，組件交互的可伸縮性、接口的通用性、組件的獨立部署、以及用來減少交互延遲、增強安全性、封裝遺留系統的中間組件
即對服務的思考，RPC是對面向過程的方式進行思考，REST是面向對象方式進行思考，
分布式服務，兩個思維集群方式發生改變
?
?
REST學習
(1)?REST架構的實現唯一使用的協議是HTTP
(2)?WS-Security是可路由，是REST唯一的安全機制(WS-SecureConversation和WS-Security)
(3)?REST事務
(4)?REST對一般性QoS的問題，REST不能支持這些一般性QoS背后的原因是，它們都需要維護“會話狀態”。有狀態（statefulness）存在明顯的缺陷（如，影響可伸縮性和錯誤恢復），但是隨著Redis之類的宣稱常數時間（即O(1)）和高性能的NoSQL存儲的出現，就有可能將會話狀態從內存中轉移到這樣的存儲中，因而可支持在多個節點間共享會話，進而可以滿足QoS的需要。
?
REST的主要優勢到底是什么？
對于基于網絡的應用來說，你怎么樣看待服務器，就會產生什么樣的架構風格，隨之產生與該架構風格相關的交互模式。
RPC架構風格將服務器看作是由一些過程組成，客戶端調用這些過程來執行特定的任務。SOAP就是RPC風格的一種架構。過程是動詞性的（做某件事），因此RPC建模是以動詞為中心的。
分布式對象架構風格認為服務器是由一些對象和對象上的方法組成，客戶端通過調用這些對象上的方法來執行特定的任務。并且客戶端調用這些對象上的方法應該就像是調用本地對象上的方法一樣，這樣開發就可以完全按照統一的面向對象方法來做。但是很可惜，這樣的抽象并不是很有效，因為分布式對象與本地對象存在著巨大的本質差別，想要掩蓋這些差別很多時候甚至是有害無益的。
REST架構風格并沒有試圖掩蓋這些差別，而是將服務器抽象為一組離散資源的集合。資源是一個抽象的概念，而不是代表某個具體的東西。注意：要真正理解REST，就一定要增強自己的抽象思維能力，充分理解到資源是抽象的。如果完全不具有抽象思維的能力，一定要將資源與數據庫中的一張表或服務器端的一個文件（HTML、Servlet、JSP、etc.）一一掛起鉤來，就無法真正理解REST了。資源是名詞性的，因此REST建模是以名詞為中心的。
上述是目前基于網絡的應用的主要的三種抽象方式。這三種不同的抽象方式會嚴重影響客戶端與服務器的交互模式，而不同交互模式的交互效率差別相當大。分布式對象的交互模式很多時候效率很低，因為掩蓋了分布式對象與本地對象的差別，很多時候都會導致細粒度的API（需要一再強調才能讓一些不明就里的架構初哥按照正確的方式來做設計）。實踐已經證明，與RPC和分布式對象相比，REST是一種對于服務器更加有效的抽象方式，將會帶來粒度更大和更有效率的交互模式。這樣的效果與Fielding設計REST的初衷是吻合的，REST就是專門為交互的性能和可伸縮性進行過優化的一種架構風格。而SOAP在設計的時候優先考慮的從來不是性能和可伸縮性，而是互操作性。除非出現奇跡，否則你種什么，就應該長出來什么。你種的是瓜，長出來的就是瓜；你種的是豆，長出來的就是豆。
Fielding寫到：“REST提供了一組架構約束，當作為一個整體來應用時，強調組件交互的可伸縮性、接口的通用性、組件的獨立部署、以及用來減少交互延遲、增強安全性、封裝遺留系統的中間組件。”
有人認為REST不是面向對象的，其實REST雖然沒有分布式對象那么面向對象，在我看來至少比RPC更加面向對象。按照《企業應用架構模式》，以動詞為中心建模是什么？是不是就是事務腳本？以名詞為中心建模是什么？是不是就是領域模型？這就扯遠了，網絡通信是否一定需要實現為面向對象的形式，我認為是不需要的。
“REST的主要優勢在我看來其實在于它是一種對于服務器的更加有效的抽象方式。”
這句話等于是，我先把一個骨架放在這里，還沒有用血肉來充實它，也就是還沒有舉出具體的實例來。具體的實例以后我們還需要來詳細討論。REST是非常簡練的，同時又是一種非常強大的抽象方式，在我看來就是從根本上簡化Web開發的一味良藥。
?
)
