移動互聯網實戰--Web Restful API設計和基礎架構

 

前言:
　　在移動互聯網的大潮中, Web Restful API逐漸成爲Web Server重要的一個分支. 移動端和服務端的交互, 主流的方式仍是經過Http協議的形式來進行. 請求以Get/Post方式, 響應以json(數據更小巧且自描述能力強)的方式佔據主流. 各大互聯網公司, 對自身的Web Api設計有各自的標準. 本文主要講述主流的幾種, 並對web server的基礎架構作個簡單的描述.

百度雲實現方案:
　　百度移動雲事業部的對雲服務的Web Api借鑑了亞馬遜的AWS實現方案. 具體可參見百度移動雲開發者網站: http://developer.baidu.com/.
　　該Restful API的設計特色, 主要由如下幾方面來描述.
　　1). URL的設計

http[s]://{server}/rest/2.0/{product}/{resource}?{query_string}

　　server: 具體服務的域名
　　product: 具體服務的產品名稱
　　resource: 具體服務的某個資源名稱
　　query_string: 具體服務的某個方法全部key/value對參數(包括函數名) 
　　2). 請求/響應數據格式
　　基於HTTP協議, 支持GET/POST兩種方式, 通常讀請求採用GET模式, 而寫請求採用POST的模式.
　　請求數據格式: 與普通的web服務並沒有區別, GET模式參數擱置在query_string中, POST模式參數擱置在POST附帶參數中
　　響應數據格式: 響應的結果和業務服務相關
　　#) 業務操做成功

{
　　"request_id":12394838223,
　　"response_params": { ... }
}

　　評註: request_id是本次請求的標識號, 用於問題查找, response_params則包含了具體業務的響應結果.
　　#) 業務操做失敗

{
　　"request_id":12394838223,
　　"error_code":30000,
　　"error_msg":"Request params not valid"
}	

　　評註: 失敗返回的結果固定包含三部分: request_id/error_code/error_msg, error_code指定錯誤碼, error_msg爲具體的出錯信息.

　　3). 業務邏輯狀態與http響應碼的綁定
　　業務結果與http響應碼的綁定, 無論是否合理, 這也算是AWS Web API的一大特點.
　　好比:

http狀態碼	業務錯誤碼	業務錯誤描述信息	業務錯誤描述信息
200
404	30605	Data Required Not Found	請求數據不存在
500	30600	Internal Server Error	服務器內部錯誤

　　評註: 業務服務層應該在http協議之上, 二者的狀態不應綁定, 至於AWS爲什麼這樣設計, 我只能說"存在即合理"

該方案實戰和點評:
　　世上沒有一個方案是完美的, 它總有它的不足存在. 這邊談談小編在工程實踐中, 對此方案所感慨的一些不足.
　　在某個具體的雲服務應用中, 特定的一個方法訪問成爲了熱點(其餘方法訪問量少). 咱們想在反向代理層(lighttpd/nginx)做分流, 讓實現FastCGI的C模塊代替原生的PHP CGI. Web Server是依據URI中的服務域名和URI PATH來匹配劃分/分流, 然而遺憾的是method方法參數在URI的query_string中, 該方案沒法實施. 若是method參數在URI中的PATH中那就好辦了.
　　儘管HTTP協議屬於網絡的應用層, 可是再細分的話, 業務層該在HTTP協議之上, 不一樣的協議層, 彼此之間應該互不影響. 業務錯誤碼和http狀態碼的綁定多少讓人有些困惑. 有些發生在Web Server層的真正404錯誤, 卻被Web API的Client SDK誤認爲了業務邏輯錯誤, 這些其實不該該發生.

我的比較推崇的作法:
　　1). Http的請求分爲URL約定規則、請求參數規則
　　URL規則: 

http://{server}/{product}/{version}/{logic}/{method}?{query_string}

　　server: 爲具體的服務域名
　　product: 爲應用工程名
　　version: 爲具體版本號, 便於未來的功能擴展, 能夠暫定爲 1.0, 2.0
　　logic: 爲具體業務邏輯的初步劃分, 好比後端管理方法, app端的請求方法
　　method: 具體業務的方法
　　具體的請求參數, 由指定的method方法決定, 全都做爲HTTP GET/POST的參數列表.
　　2). Http的響應規則
　　HTTP響應碼爲200, 邏輯結果以JSON字符串的形式組織:
　　若是響應結果正確,則返回結果以下所示:

{
　　"success": true,
　　"result_value" : {
　　　　/* 由具體的業務方法決定 */
　　}
}

　　若是響應結果失敗,則返回以下結果:

{
　　"success": false,
　　"request_id": 10001,
　　"err_code": 1001,
　　"err_msg": "Internal Server Error"
}

　　借鑑了AWS的設計思路, 同時拋棄了業務錯誤碼與HTTP狀態碼的綁定, 同時把method/logic/version擱置在URI中的PATH中, 便於WebServer的分流. 

Web Server的基礎架構
　　對於Web Server的基礎架構, 大體有如下幾種流行的方式.
　　1). 採用LVS的方式:
　　　　對內部多個節點(IP地址)的訪問, 對外抽象爲同一個IP地址, 這就是LVS的方式. 其能夠理解爲軟件級負載均衡方式(須要依賴硬件)
　　2). 採用Nginx/Apache的反向代理:
　　
　　評註:Nginx的反向代理,能夠方便對靜態資源和動態資源作分離, 對小企業而言, 是最經常使用的一種方式.
　　3). LVS和Nginx/Apache反向代理的結合
　　

　　注: 圖片來自網絡.