使用Jayrock開源組件開發基於JSON-RPC協議的接口

最近接手一個之前的項目，無心間發現此項目開發接口的組件：Jayrock（接口組件估計用的少，用的最多的估計是這個Jayrock.json.dll，用於解析json）

如下是Jayrock的介紹官網：

https://atifaziz.github.io/projects/jayrock/

若是你在開發上使用了該組件，上面的官網會是一個不錯的入門教程。

在研究的過程當中，發現Jayrock有如下的特定，主要從開發角度方向進行分析。

優勢以下：

一、接口開發和部署簡單，直接繼承組件的JsonRpcHandler，而後進行本身的業務開發，然而，你可使用實體的ashx文件或者在web.config中全局接管httphandler的方式使用；

二、有接口的幫助頁面和測試頁面，這個方式其實很是適合移動端或者第三方須要調用的人員使用，能快速的瞭解接口的用途和測試數據返回的json格式；

三、本域調用後臺的接口時，直接使用proxy模式，在html的頁面自動生成一個接口js調用類直接使用方法的形式調用接口，拋棄的傳統的寫請求的方式（確實節省前端開發人員的工做量）；

四、跨域時，只要在後臺代碼開發的接口上，標誌跨域標識，直接使用getrpc模式，便可輕鬆的進行跨域調用（跨域的JS只能是GET方式獲取），可是每個接口的代碼就得本身寫了；

五、接口json格式採用了jsonrpc格式，對於json的定義，提供了統一性；

缺點，也是美中不足的吧：

一、因爲整個組件採用jsonrpc格式，那麼組件在封裝的時候，就上傳照片或者文件來講，徹底沒有考慮會使用流的形式，只能講文件轉成base64格式，而後裝載進json字段中，一併提交；那麼問題來了，base64講圖片轉換以後，數據就會變的大不少，流量損失比較大；

二、雖然方法能夠寫註釋，可是針對每一個參數的註釋確沒有，多是做者的思路是，參數命名直觀便可；

三、接口的參數上，每一個都是必須的，不能不傳遞，可是咱們開發接口的時候，有些特定的需求，會使一些參數傳遞爲null，好比搜索接口就是一個典型的例子；（此觀點是錯誤的，通過深刻研究，已經解決，詳細請看此篇文章）

四、總體採用jsonrpc協議後，流量上天然是大了那麼一丁點的了，可是，對於通常的業務系統而言，這些能夠忽略不計；

如下是我在開發上的一些圖片流程：

一、接口的開發

　　1）物理文件模式：

　　

　　2）web.config接管模式

　　

二、接口的幫助頁面和測試頁面

　　1）幫助頁面，清晰瞭然

　　

　　2）接口的測試頁面，自動展現出哪些參數，給移動端開發確實是不錯選擇

　　

三、本域調用：

　　

　　是否是很是的簡單，很是的爽；

四、跨域調用形式，這個算是我艱辛萬苦在老外的一個網站上的一個問題上找到的

　　使用很是的簡單，只要在接口上標記Idempotent = true便可，而後以下調用便可：

　　

五、JSON-RPC協議說明，直接引入網址：http://www.json-rpc.org/

　　http://blog.csdn.net/hahahacff/article/details/29119077

總結：

　　以上就是我對Jayrock組件的研究，其實，以上說到的優勢mvc的web api就能所有實現了，幫助和測試頁面只需在nuget上下載個擴展便可；

 

如下是組件的所有文件，包括一些例子也在裏面，因爲谷歌代碼管理即將關閉（只是改成只讀模式），因此我整理了一份最全的：（連接: https://pan.baidu.com/s/1jIECHNK 密碼: nvee）

若是要更好的開發體驗，那麼能夠嘗試如下升級版本：http://www.cnblogs.com/EasonJim/p/6027234.html