在JavaEye論壇上回答網(wǎng)友joyjiang的疑問：“REST的優(yōu)勢到底是什么?開發(fā)效率?文檔的管理?url的直觀?還是其它的什么優(yōu)勢呢?”
REST的主要優(yōu)勢在我看來其實在于它是一種對于服務(wù)器的更加有效的抽象方式。
對于基于網(wǎng)絡(luò)的應(yīng)用來說，你怎么樣看待服務(wù)器，就會產(chǎn)生什么樣的架構(gòu)風(fēng)格，隨之產(chǎn)生與該架構(gòu)風(fēng)格相關(guān)的交互模式。
RPC架構(gòu)風(fēng)格將服務(wù)器看作是由一些過程組成，客戶端調(diào)用這些過程來執(zhí)行特定的任務(wù)。SOAP就是RPC風(fēng)格的一種架構(gòu)。過程是動詞性的（做某件事），因此RPC建模是以動詞為中心的。
分布式對象架構(gòu)風(fēng)格認(rèn)
為服務(wù)器是由一些對象和對象上的方法組成，客戶端通過調(diào)用這些對象上的方法來執(zhí)行特定的任務(wù)。并且客戶端調(diào)用這些對象上的方法應(yīng)該就像是調(diào)用本地對象上的
方法一樣，這樣開發(fā)就可以完全按照統(tǒng)一的面向?qū)ο蠓椒▉碜觥５呛芸上В@樣的抽象并不是很有效，因為分布式對象與本地對象存在著巨大的本質(zhì)差別，想要掩
蓋這些差別很多時候甚至是有害無益的。
REST架構(gòu)風(fēng)格并
沒有試圖掩蓋這些差別，而是將服務(wù)器抽象為一組離散資源的集合。資源是一個抽象的概念，而不是代表某個具體的東西。注意：要真正理解REST，就一定要增
強(qiáng)自己的抽象思維能力，充分理解到資源是抽象的。如果完全不具有抽象思維的能力，一定要將資源與數(shù)據(jù)庫中的一張表或服務(wù)器端的一個文件（HTML、
Servlet、JSP、etc.）一一掛起鉤來，就無法真正理解REST了。資源是名詞性的，因此REST建模是以名詞為中心的。
上述
是目前基于網(wǎng)絡(luò)的應(yīng)用的主要的三種抽象方式。這三種不同的抽象方式會嚴(yán)重影響客戶端與服務(wù)器的交互模式，而不同交互模式的交互效率差別相當(dāng)大。分布式對象
的交互模式很多時候效率很低，因為掩蓋了分布式對象與本地對象的差別，很多時候都會導(dǎo)致細(xì)粒度的API（需要一再強(qiáng)調(diào)才能讓一些不明就里的架構(gòu)初哥按照正
確的方式來做設(shè)計）。實踐已經(jīng)證明，與RPC和分布式對象相比，REST是一種對于服務(wù)器更加有效的抽象方式，將會帶來粒度更大和更有效率的交互模式。這
樣的效果與Fielding設(shè)計REST的初衷是吻合的，REST就是專門為交互的性能和可伸縮性進(jìn)行過優(yōu)化的一種架構(gòu)風(fēng)格。而SOAP在設(shè)計的時候優(yōu)先
考慮的從來不是性能和可伸縮性，而是互操作性。除非出現(xiàn)奇跡，否則你種什么，就應(yīng)該長出來什么。你種的是瓜，長出來的就是瓜；你種的是豆，長出來的就是
豆。
Fielding寫到：“
REST提供了一組架構(gòu)約束，當(dāng)作為一個整體來應(yīng)用時，強(qiáng)調(diào)組件交互的可伸縮性、接口的通用性、組件的獨立部署、以及用來減少交互延遲、增強(qiáng)安全性、封裝遺留系統(tǒng)的中間組件。”
有
人認(rèn)為REST不是面向?qū)ο蟮模鋵峈EST雖然沒有分布式對象那么面向?qū)ο螅谖铱磥碇辽俦萊PC更加面向?qū)ο蟆０凑铡镀髽I(yè)應(yīng)用架構(gòu)模式》，以動詞為中
心建模是什么？是不是就是事務(wù)腳本？以名詞為中心建模是什么？是不是就是領(lǐng)域模型？這就扯遠(yuǎn)了，網(wǎng)絡(luò)通信是否一定需要實現(xiàn)為面向?qū)ο蟮男问剑艺J(rèn)為是不需
要的。
“REST的主要優(yōu)勢在我看來其實在于它是一種對于服務(wù)器的更加有效的抽象方式。”
這句話等于是，我先把一個骨架放在這里，還沒有用血肉來充實它，也就是還沒有舉出具體的實例來。具體的實例以后我們還需要來詳細(xì)討論。REST是非常簡練的，同時又是一種非常強(qiáng)大的抽象方式，在我看來就是從根本上簡化Web開發(fā)的一味良藥。