RESTFUL太死板、SOAP太麻煩，那就是JSON RPC吧。
先說一句，不管是RESTFUL還是JSON RPC，其實(shí)都可以跟HTTP協(xié)議無關(guān)。只不過HTTP的特點(diǎn)天然適合于承載RESTFUL和JSON RPC。
RESTFUL對應(yīng)用程序的影響，絕非僅是WEB層面的HTTP METHODS和URL，這充其量只是形式正確。而更根本的是影響了軟件分析和設(shè)計的思維，Roy Fielding博士稱之為“架構(gòu)風(fēng)格”，要用Resource的理念來建模，將所有的東西抽象成一組資源。其實(shí)這個環(huán)節(jié)，跟WEB與否沒什么關(guān)系。
一般來講，軟件架構(gòu)設(shè)計里有Domain Object的概念。但領(lǐng)域?qū)ο蠛唾Y源的概念還不盡一樣，未必是一一對應(yīng)或等價的。在10年前吵得天翻地覆的Martin Fowler的“充血模型”討論中，領(lǐng)域?qū)ο笠舶琌peration，不一定都是靜態(tài)的“資源”。
這就是說，RESTFUL的設(shè)計理念，以“Resource”的架構(gòu)風(fēng)格為神、以"HTTP METHOD/URI"的展現(xiàn)風(fēng)格為形（Fielding又說Restful與通信協(xié)議無關(guān)，只要是超文本驅(qū)動的即可），提供了一種嚴(yán)謹(jǐn)?shù)?、理想化的方法來架?gòu)WEB。而今我們回頭看，這其實(shí)是副鐐銬。帶著鐐銬去設(shè)計大型軟件，不會很舒服的。
認(rèn)真讀過Roy Fielding博士的論文的同志們應(yīng)該了解，F(xiàn)ielding至始至終是以WEB(萬維網(wǎng))為背景在討論，沒說Restful適用于各類B/S模式的應(yīng)用。況且他的論文發(fā)表于2000年，15年前的Internet規(guī)模和應(yīng)用復(fù)雜度遠(yuǎn)遜于今日，互聯(lián)網(wǎng)上的東西，要抽象成靜態(tài)資源還真不難。后來社交媒體井噴一樣地出現(xiàn)了，各大網(wǎng)站都對外提供掛羊頭賣狗肉的Restful的API，F(xiàn)ielding博士坐不住了，于2008年出來發(fā)文說你們這些都TMD是假的，然后提出了N條約束，想正本清源?？墒强纯茨切┘s束，就更讓人望洋興嘆了。
所以我的觀點(diǎn)是，RESTFUL可能快要成為一種學(xué)術(shù)上的架構(gòu)理論了，在越來越豐富、復(fù)雜的WEB環(huán)境下（更別說企業(yè)應(yīng)用），帶著RESTFUL這副鐐銬跳舞，不說舉步維艱，至少舞姿不會太優(yōu)美。
----------------
JSON RPC就沒啥嚴(yán)格的約束了。管你Server端什么架構(gòu)風(fēng)格，只要用一層Facede統(tǒng)一包裝下，將結(jié)果序列化成JSON即可，API粒度你根據(jù)業(yè)務(wù)需要自己控制。還有個便利就是：JSON與JAVASCRIPT天然的融合，讓前段所謂的Deserialization省心省力。
當(dāng)然自由的副作用就是容易混亂，JSON沒有XML那種嚴(yán)格的Schema（現(xiàn)在已經(jīng)有了吧），語義化程度也稍差，API的命名也沒啥約定。這就需要自己花力氣去訂規(guī)則。否則，當(dāng)一個應(yīng)用有100個API的時候，花樣百出。
本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請
點(diǎn)擊舉報。
