程序員的自我救贖---11.1：RPC接口使用規範

《前言》

（一） Winner2.0 框架基礎分析

（二）PLSQL報表系統

（三）SSO單點登陸

（四） 短信中心與消息中心

（五）錢包系統

（六）GPU支付中心

（七）權限系統

（八）監控系統

（九）會員中心

（十） APP版本控制系統

（十一）Winner前端框架與RPC接口規範講解

（十二）上層應用案例

（十三）總結

 

《RPC接口使用規範》

 

不知道啥時候開始好像一會兒都流行叫「RPC」了。以前咱們都叫「API」的，爲此我特意百度了一下才知道原來：

API（Application Programming Interface，應用程序編程接口）

RPC（Remote Procedure Call），遠程過程調用）

這樣一看確實叫RPC更合適一下，細緻講一下咱們Winner2.0中接口請求規範，咱們從簡到繁的說一下演變過程（如下就簡稱RPC）。

 

首先在1.0時代，咱們當時也沒有不少思路，只作了簡單簽名驗證也沒有考慮權限、版本等問題，主要是用WebService。

咱們看一下常規狀況咱們是這麼用的：

 

 

咱們的目的是爲了防止WebService 接口被惡意調用，尤爲是篡改數據後調用因此用了兩種手段作安全驗證：

1，使用RSA對參數加密（RSA是非對稱加密，公鑰加密私鑰解密，通常使用兩對RSA）。

2，使用MD5作簽名驗證（客戶端與服務端約定一個字符串作加密種子，將全部參數+加密種子 算出來惟一的md5值）

 

這樣作基本對於安全性而言已經夠了，可是在使用過程當中五六年下來老是以爲用着不順手。大體幾點以下：

 

A，接口沒有權限管制。好比咱們一個接口同時有A、B兩個項目調用，這個時候我想中止給B項目使用，接口就沒有控制權。

     這種狀況常常出如今給第三方調用時候，咱們不想給第三方使用了，這個時候又關不掉，關掉了咱們本身的項目也用不了了。

 

B，咱們這樣寫接口沒有版本的概念。一樣以第三方調用咱們的接口來舉例，若是咱們升級項目更改了參數，全部的第三方就開始

    罵娘了，每一個第三方客戶端都要去升級系統，並且咱們一刀切調用不見得有時間來配合咱們升級。有版本號的話，咱們可讓老用戶

    依然能夠繼續使用，新接入的就使用最新的接口。

 

C，對於移動客戶端沒有管理概念。 這個屬於特殊的業務，咱們公司的硬件終端若是我想限制某一臺終端調用，以前的作法是不行的。

 

D：參數過多時代碼繁瑣。 若是9個參數，客戶端就要給8個參數依次加密，固然能夠寫工具類處理，但仍是繁瑣了。

 

F：沒有統一的Json返回參數規範。每一個項目都是本身定義返回結果，沒有規範。客戶端開發時沒有規律可循。

 

另外還有一些小問題，但最主要的就這幾點，因此咱們在Winner2.0中咱們商量出了一套標準，全部的接口基於這套標準開發。

首先，得益於MVC的到來，咱們基本放棄了使用Webservice這種方式提供接口，轉而使用WebAPI的形式。 

其次，咱們接口只接收三個固定參數：商戶號，Json數據，簽名字符串。

最後，咱們統一了返回Json的數據標準，以及錯誤編碼。

 

這裏我貼一張Jason 寫的接口文檔中的接口API協議：

 

 

 公共參數就是全部接口都須要接收這些基本的參數，再一個子Json纔是具體的傳值參數。 這段Json用商戶號對應的MD5種子

加密，主要也省去了每一個參數客戶端單獨加密，服務端又單獨解密的繁瑣。

 

與此同時，咱們還須要上送客戶端的硬件id，會用的信息，商戶信息等。主要就在服務端能作更細緻的控制。 

 

差很少就說道這裏吧，有興趣一塊兒探討Winner框架的能夠加咱們QQ羣：261083244。或者掃描左側二維碼加羣。