先說結(jié)論
JSON-RPC比RESTful API好很多夷野。
解釋
我厭惡restful API如同我厭惡OOP忧设；但與其說我厭惡restful，倒不如說我厭惡鼓吹restful API的一些偽·程序員赌渣。
很多鼓吹restful API的程序員李剖，實(shí)際上并不理解restful的設(shè)計(jì)理念略吨，純粹是在人言亦言励饵，隨便看了幾篇網(wǎng)文在說restful飞盆，自己便也更著鼓吹肿嘲。
做為一個(gè)合格的技術(shù)人員融击，最基礎(chǔ)的要求是要對(duì)自己所使用的技術(shù)有了解，明白各種技術(shù)的適用場景雳窟，然后因地制宜尊浪。
restful首先是要求必須把所有的應(yīng)用定義成為“resource”，然后只能針對(duì)資源做有限的四種操作封救。
這是對(duì)API一個(gè)非常糟糕的抽象拇涤，有太多現(xiàn)實(shí)中需要的API，無法順當(dāng)?shù)娜谌氲絩estful所定義的規(guī)范中誉结。
比方說鹅士，user login / resetpassword等等。
restful的信徒惩坑，他們會(huì)說可以根據(jù)這個(gè)那個(gè)規(guī)范掉盅，把login / password等也納入為某種資源也拜，然后進(jìn)行增刪改查。這在我看來趾痘，純粹是在解決一些原本不存在慢哈，根本不需要解決的問題，純浪費(fèi)永票。
所有的接口卵贱，服務(wù)器端原本就存在有相應(yīng)的函數(shù)，它們本來就有自身的命名空間侣集，接受的參數(shù)键俱、返回值、異常等等世分。
采用輕便的方式暴露出來即可编振。
無需把一堆函數(shù)重新歸納到“資源”，再削減腦袋把所有的操作都映射為“增刪改查”罚攀。
對(duì)應(yīng)到web上党觅，rpc的成熟方案非常多雌澄，有古老的soap斋泄，也有輕量的json rpc。
JSON rpc基本上僅是要求所有的請(qǐng)求必須有msg id镐牺，有函數(shù)名炫掐，然后可定義參數(shù)，并且區(qū)分返回值與異常睬涧；也可定義『命名空間』來對(duì)函數(shù)模塊做劃分募胃。
這與大多數(shù)語言的模塊、函數(shù)定義相符畦浓，使用起來是非常便利的痹束。
很多json rpc是供web前端ajax調(diào)用，若前端調(diào)用抽象得當(dāng)讶请，調(diào)用遠(yuǎn)程API祷嘶，實(shí)際上與調(diào)用本地函數(shù)無甚區(qū)別。
實(shí)際上夺溢，json rpc也未必需要跟http綁定论巍，即便是在web上，它也可以走web socket风响，這樣子嘉汰，前端可以使用同一web socket管道批量發(fā)送請(qǐng)求，而服務(wù)器端亂序返回結(jié)果時(shí)状勤，前端也可以根據(jù)msg id做準(zhǔn)確的回調(diào)鞋怀。
websocket双泪，批量調(diào)用，亂序返回密似，這些都可以顯著提高API的輸出吞吐攒读，這些是在json rpc的設(shè)計(jì)考量內(nèi)。
調(diào)用更方便辛友，性能也更好薄扁，兩全其美是完全可能的。
想當(dāng)然的為了“快”废累，為了“簡單”就必須犧牲別的邓梅，這是嚴(yán)重的思維誤區(qū)。
有些方案邑滨，純粹就是糟糕的方案日缨。
restful API僅適用與業(yè)務(wù)非常簡單的場景，比方說掖看，就是為了提供少量數(shù)據(jù)表單的增刪改查匣距。而這種場景實(shí)在是太過簡單，實(shí)際中幾乎找不到哎壳。
其它優(yōu)秀的方案毅待？可以看看：
另外
發(fā)現(xiàn)老外一篇舊文：http://rob.conery.io/2012/02/28/someone-save-us-from-rest/ 推薦大家去看看~
