針對
--->非開放性平台
--->公司內部產品
接口特點匯總：
1、因為是非開放性的，所以所有的接口都是封閉的，只對公司內部的產品有效；
2、因為是非開放性的，所以OAuth那套協議是行不通的，因為沒有中間用戶的授權過程；
3、有點接口需要用戶登錄才能訪問；
4、有點接口不需要用戶登錄就可訪問；
針對以上特點，移動端與服務端的通信就需要2把鑰匙，即2個token。
第一個token是針對接口的（api_token）；
第二個token是針對用戶的（user_token）；
先說第一個token（api_token）
它的職責是保持接口訪問的隱蔽性和有效性，保證接口只能給自家人用，怎么做到？參考思路如下：
按服務器端和客戶端都擁有的共同屬性生成一個隨機串，客戶端生成這個串，服務器也按同樣算法生成一個串，用來校驗客戶端的串。
現在的接口基本是mvc模式，URL基本是restful風格，URL大體格式如下：
http://blog.snsgou.com/模塊名/控制器名/方法名?參數名1=參數值1&參數名2=參數值2&參數名3=參數值3
接口token生成規則參考如下：
api_token = md5 ('模塊名' + '控制器名' + '方法名' + '2013-12-18' + '加密密鑰') = 770fed4ca2aabd20ae9a5dd774711de2
其中的
1、 '2013-12-18' 為當天時間，
2、'加密密鑰' 為私有的加密密鑰，手機端需要在服務端注冊一個“接口使用者”賬號后，系統會分配一個賬號及密碼，數據表設計參考如下：
字段名 字段類型 注釋
client_id varchar(20) 客戶端ID
client_secret varchar(20) 客戶端(加密)密鑰
（注：只列出了核心字段，其它的再擴展吧！！！）
再說第二個token（user_token）
它的職責是保護用戶的用戶名及密碼多次提交，以防密碼泄露。
如果接口需要用戶登錄，其訪問流程如下：
1、用戶提交“用戶名”和“密碼”，實現登錄（條件允許，這一步最好走https）；
2、登錄成功后，服務端返回一個 user_token，生成規則參考如下：
user_token = md5('用戶的uid' + 'Unix時間戳') = etye0fgkgk4ca2aabd20ae9a5dd77471fgf
服務端用數據表維護user_token的狀態，表設計如下：
字段名 字段類型 注釋
user_id int 用戶ID
user_token varchar(36) 用戶token
expire_time int 過期時間（Unix時間戳）
（注：只列出了核心字段，其它的再擴展吧！！！）
服務端生成 user_token 后，返回給客戶端（自己存儲），客戶端每次接口請求時，如果接口需要用戶登錄才能訪問，則需要把 user_id 與 user_token 傳回給服務端，服務端接受到這2個參數后，需要做以下幾步：
1、檢測 api_token的有效性；
2、刪除過期的 user_token 表記錄；
3、根據 user_id，user_token 獲取表記錄，如果表記錄不存在，直接返回錯誤，如果記錄存在，則進行下一步；
4、更新 user_token 的過期時間（延期，保證其有效期內連續操作不掉線）；
5、返回接口數據；
接口用例如下：
1、發布日志
URL： http://blog.snsgou.com/blog/Index/addBlog?client_id=wt3734wy636dhd3636sr5858t6&api_token=880fed4ca2aabd20ae9a5dd774711de2&user_token=etye0fgkgk4ca2aabd20ae9a5dd77471fgf&user_id=12
請求方式： POST
POST參數：title=我是標題&content=我是內容
返回數據：
{
'code' => 1, // 1:成功 0:失敗
'msg' => '操作成功' // 登錄失敗、無權訪問
'data' => []
}
對於 api_token 的校驗，其安全性還可再增強：
增強地方一：
再增加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 | int | api編號 |
| 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，服務端的identity_key和客戶端的identity_key 進行校對，如果不相等，表示被竄改過，接下來怎么操作，自己看着辦吧！