增強地方一：
再增加2張表，乙個介面表，乙個授權表，設計參考如下：
介面表欄位名
字段型別
注釋api_id
int介面id
api_name
varchar(120)
介面名，以"/"作為分割線，如 blog/index/addblog
api_domain
varchar(256)
所屬領域
is_enabled
tinyint(1)
是否可用 1:可用 0:不可用
add_time
int新增時間（戳）
（注：只列出了核心字段，其它的再擴充套件吧！！！）
授權表欄位名
字段型別
注釋client_id
int客戶端id
api_id
intapi編號
api_name
varchar(120)
介面名，以"/"作為分割線，如 blog/index/addblog
is_enabled
tinyint(1)
是否可用 1:可用 0:不可用
add_time
int新增時間（戳）
expire_time
int過期時間（戳）
（注：只列出了核心字段，其它的再擴充套件吧！！！）
執行過程如下：
1、移動端與服務端生成的 api_token 進行對比，如果不相等，則直接返回錯誤，否則，進入下一步；
2、根據介面url，組裝 api_name，再加上客戶端傳回的 client_id 為引數，查詢 「授權表」記錄，如果記錄存在，且有效（是否可用，是否過期），則表示許可權驗證通過，返回介面資料，否則返回錯誤資訊；
增強地方二：
對於一些很特殊的介面，怎麼特殊，哪些算特殊，我也不知道，總而言之，就是感覺http請求有可能被劫取，傳遞引數有可能被竄改等情況，還是舉個例子來說吧：
有個直接轉賬介面，頁面上 我輸入的是5元，表示我要給對方某某轉賬5元，結果在http傳遞過程中，被人劫取並竄改成了 10000元，而且入賬物件改成了「黑客」的賬號，那不是虧大發了，思考了一下，應該有2種方案解決這個問題，
方案一：走https，這個就不多說，比較公認的安全機制；
方案二：走數字簽名，實現原理如下：
乙個http請求，假如需要傳遞如下3個引數
引數名1=引數值1
引數名2=引數值2
引數名3=引數值3
我們可以再追加乙個引數，該引數的名為identity_key （名字是什麼不重要），該引數的值為前幾個引數值按順序相加，再加密後的結果。
即：identity_key = md5('引數值1' + '引數值2' + '引數值3' + '加密金鑰');
於是，最終傳遞的引數有：
引數名1=引數值1
引數名2=引數值2
引數名3=引數值3
client_id=client_id值
identity_key=md5('引數值1' + '引數值2' + '引數值3'+ 'client_id值' + '加密金鑰')
服務端接到引數後，再按相同的加密規則重新生成乙份identity_key，服務端的identity_key和客戶端的identity_key 進行校對，如果不相等，表示被竄改過，接下來怎麼操作，自己看著辦吧！
移動端與PHP服務端介面通訊流程設計 基礎版
非開放性平台 公司內部產品 介面特點彙總 1 因為是非開放性的，所以所有的介面都是封閉的，只對公司內部的產品有效 2 因為是非開放性的，所以oauth那套協議是行不通的，因為沒有中間使用者的授權過程 3 有點介面需要使用者登入才能訪問 4 有點介面不需要使用者登入就可訪問 針對以上特點，移動端與服務...
移動端與PHP服務端介面通訊流程設計 基礎版
非開放性平台 公司內部產品 介面特點彙總 1 因為是非開放性的，所以所有的介面都是封閉的，只對公司內部的產品有效 2 因為是非開放性的，所以oauth那套協議是行不通的，因為沒有中間使用者的授權過程 3 有點介面需要使用者登入才能訪問 4 有點介面不需要使用者登入就可訪問 針對以上特點，移動端與服務...
移動端與PHP服務端介面通訊流程設計 基礎版
針對 非開放性平台 公司內部產品 介面特點彙總 1 因為是非開放性的，所以所有的介面都是封閉的，只對公司內部的產品有效 2 因為是非開放性的，所以oauth那套協議是行不通的，因為沒有中間使用者的授權過程 3 有點介面需要使用者登入才能訪問 4 有點介面不需要使用者登入就可訪問 針對以上特點，移動端...