在JavaEye論壇上回答網友joyjiang的疑問：“REST的優勢到底是什么?開發效率?文檔的管理?url的直觀?還是其它的什么優勢呢?”
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開發的一味良藥。