由一個問題引發的思考：WEB開發中，使用JSON-RPC好，仍是RESTful API好？

原由：

研究zabbix的API設計風格。查看zabbix官網API文檔，能夠看到使用的是json-rpc:2.0

隨後搜索到知乎上的一個問題討論：https://www.zhihu.com/question/28570307 即標題中的問題。

 

仔細研究，問題不斷髮散再發散，整理一下，如下內容是看了不少篇相關知識後的我的理解：

 

一、RPC是什麼？

參考：https://www.zhihu.com/question/25536695/answer/221638079

RPC是指遠程過程調用。服務器A要調用服務器B上的某個方法，因爲內存空間不一樣，沒法直接調用，須要經過網絡來表達調用的語義和傳達調用的數據。需解決如下問題：

通訊問題：在服務器A與B之間創建起TCP鏈接（有答案說UDP也能夠）；TCP、UDP是屬於傳輸層的協議

參數的序列化和反序列化：參數經過網絡傳輸，需把服務器A內存裏的內容序列化後進行傳輸。

方法映射：參數中包含着要調用的方法，服務器B必須創建起參數與所要調用方法的映射關係

服務器B執行完方法後返回，一樣經歷上述過程。

 

二、json-RPC是什麼

json-rpc 2.0規範：http://wiki.geekdream.com/Specification/json-rpc_2.0.html

JSON-RPC是一個無狀態且輕量級的遠程過程調用(RPC)協議。 本規範主要定義了一些數據結構及其相關的處理規則。它容許運行在基於socket,http等諸多不一樣消息傳輸環境的同一進程中。

簡單來講，就是定義了各個RPC各參數規範。如method表示方法，param表示參數。服務器B拿到這個東西就是知道了服務器A要調用什麼方法，參數是什麼。

它是運行在socket、http、websocket等協議之上的。注意http、websocket已是屬於應用層了。

 

三、什麼是websocket？它和socket有什麼區別？

介紹websocket: https://blog.csdn.net/wwd0501/article/details/54582912

websocket首先是一個應用層協議，這點與http相同。

與http不一樣的是，它能夠創建服務器A與服務器B之間的一個長鏈接（相似於TCP中的長鏈接），以後能夠發送多個請求。而http每個請求都是獨立的。據介紹，websocket創建長鏈接時，使用http，以後的請求與返回，則不須要http協議了。

 

socket是傳輸層與應用層之間的一個抽象層，爲應用層屏蔽了傳輸層複雜的協議。

 

四、什麼是RESTful？

restful是一種API設計風格。這裏能夠發現，其實restful和json-rpc實際上是沒有可比性的。其對比的應該是RPC.

restful必須依賴於http，由於它須要http請求的類型（post、get、put、delete）來標榜對該資源進行如何的處理。

restful設計難點：須要將全部的接口抽象成某種資源

如想delete多個id怎麼辦？所有寫在url中嗎（delete沒有body）？不，你應該把刪除多個ID抽象成某個任務（即抽象成另外一種資源），而後對這個資源使用post。好比用戶的登陸和登出，不適合對用戶這個資源進行操做，應該抽象成對session這個資源進行操做。

想使用restful必需要有這樣的抽象能力。。

知乎對restful一個總結（我的以爲挺到位的）：

看Url就知道要什麼（資源）
看http method就知道幹什麼
看http status code就知道結果如何
 

必定要有以資源爲主體的思惟。以前也有人說過restful是名詞，rpc是動詞，大概想表述的也是這個意思。

 

五、知乎中有人說json-rpc性能比restful好？

實際上是json-rpc能運行在相似於websocket上，是websocket的性能比http好。這種說法有點問題。

像zabbix,json-rpc底層承載仍是使用http，反而須要序列化和反序列化的時間，性能好？不見得吧。

 

六、說回zabbix，其API設計風格究竟是咋樣的？

首先，開放的API都是使用http的post方法調用的，post的參數遵循json-rpc2.0的規範。若是把全部的API接口當作一種資源，那它的這個API能夠說是遵循了restful風格。

其次，最新奇的一點來了，其API的URL只有一個！！只有一個！！格式以下：

POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc

{"jsonrpc":"2.0","method":"apiinfo.version","id":1,"auth":null,"params":{}}
去看了api_jsonrpc.php，這個php腳本要解決的就是，首先拿到http的body數據，接下來用json-rpc2.0規範去解析，拿到method究竟是什麼，接下來去調用相應的方法。這個腳本作的就是RPC中提到的要解決方法映射問題。

 

有意思的是，method全都是以這樣的形式A.B，給人一種感受，A是類，B是A中某個方法。zabbix中全部的方法都用php腳本實現了，對應的每個A都是獨立的一個php文件，B是A中的某個方法，且名稱是一一對應的，即無需維護參數中的名稱與調用方法的映射關係。

假設不使用zabbix的Php腳原本實現相似的功能，使用類的getMethod的方式，經過反射來調用我的以爲也是可行，固然方法名稱天然也是要一一對應的。

 

暫時不能理解，爲何zabbix要這樣設計（僅用一個URL，在json-rpc的method字段去標註具體的方法）？或者這樣設計的好處在哪裏？知乎上有人這樣說：

我見過最高明的restful設計，是隻使用一個url，而後，用post請求，傳method動詞參數。可謂一個restful在手，打遍天下無敵手。

這難不成說的就是zabbix？？？？

 

最後，引用知乎上的一段話：

所謂代碼風格、接口形式、各類林林總總的格式規定，其實都是爲了在團隊內部造成共識、防止我的習慣差別引發的混亂。JSON-RPC固然也是有規範的，但相比REST實在寬鬆太多了。

若是一個開發團隊規定必須在url裏寫action，全部請求都是POST，能夠嗎？固然也沒問題，只是不要拿出去標榜本身寫的是RESTful API就行。

規範最終仍是爲了開發者和軟件產品服務的，若是它能帶來便利、減小混亂，就值得用；反之，若是帶來的麻煩比解決的還多，那就犯不上純粹跟風追流行了。（做者：Vincross 連接：https://www.zhihu.com/question/28570307/answer/163638731） --------------------- 做者：x6696 來源：CSDN 原文：https://blog.csdn.net/x6696/article/details/81839893 版權聲明：本文爲博主原創文章，轉載請附上博文連接！