WebAPI 實現先後端分離

隨着Web技術的發展，如今各類框架，前端的，後端的，數不勝數。全棧工程師的壓力愈來愈大。

如今的前端的框架，既能夠作各類Web，又能夠作各類APP，前端框架更新換代愈來愈快，愈來愈多。

傳統的模式

前端和後端進行調試，修改都很是麻煩。每每前端配合後端很痛苦，後端也嫌前端麻煩。

（無解，能動手解決的事，儘可能別動嘴。辦公室應該常備一些，繃帶，止血條，速效救心丸等藥品。爲了阻止事態升級，辦公室要增強刀具管制條例。）

先後端分離

前端根據事先約定好的文檔，能夠本身摸擬數據，而後開發，測試，調試UI，發佈到線上時把API接口改爲線上API接口，便可完事。

前端往後增長新功能，修改UI，本身修改，本身編譯更新本身UI站點，發佈線上只要調上線上API接口便可。並不須要麻煩到後端。二者工做進行分離。

後端須要跟前端商量好接口，寫好接口文檔，在接口功能上相互溝通（其實至關於需求相互溝通），一旦接口文檔訂好以後，只需按事先約定實現API接口即口。把項目編譯好發佈到線上服務器。便可完事。

後端實現WebApi接口，還能夠面對各類調用，如PC端web，手機APP，或者其它設備。一個接口多種調用，實現代碼去重。

工做模式分析

對前端和後端進行分離。各司其職，各自在本身的領域集中精力研究。更能有效的加深技術深度。

 

先後端分離的模式，你須要N名前端工程師和N名後端工程師。

首先咱們要約定一些返回基本的格式，好比用XML，仍是JSON。結果大多數前端都是喜歡JSON，由於JS天生就支持JSON。我貼出一些示例代碼

  {
    "ResultCode": 1300,
    "Message":"權限不足",
    "Data":null,
  }

  {
    "ResultCode": 1600,
    "Message":"邏輯異常",
    "Data":null,
    "DetailError":{
    "ErrCode":1601001,
    "ErrMsg":"金額必須大於>0"
    }
  }

返回參數說明

參數名	類型	是否必有	說明
ResultCode	int	是	返回碼
Message	string	是	結果說明
DetailError	josn	否	具體錯誤
Data	josn	否	數據

 

 

 

 

 

 

 

 

ResultCode

ResultCode	說明
1000	成功
1100	服務器異常
1200	身份驗證異常
1300	權限不足
1400	傳遞參數驗證不經過
1500	版本異常
1600	業務邏輯異常
1700	系統成升級中
1800	該接口己棄用

 

 

 

 

 

 

 

 

 

 

具體異常

這是一個有點爭議的地方，有不少業務邏輯異常，出於對用戶的友好提示。一些生澀難懂的錯誤提示，直接給到用戶，用戶一臉懵逼。可是後端卻不能修改爲友好提示，這樣不方便調試，尋找問題緣由。

通常來說，前端能夠自動修改友好提示給用戶。

若是後端返回字符串，前端寫死在代碼中，萬一，某一天後端認爲這個描述更符合場景，修改的字符串。敵軍還有30秒到達戰場。

建議：儘可能使用異常代碼，你們能夠看到上面貼出例子，就使用的異常代碼。每種異常都有惟一編號，描述能夠更改。可是編號不變。

用戶異常（1601000）	說明
1601001	帳號/密碼錯誤
1601002	帳號被冰凍
1601003	原密碼不對

 

 

 

 

版本控制

 每一個API都有一個版本，其實也是就針對APP，若是是WEB端的，都是直接升級的由於B/S結構自己就是存在升級方便的優點，只須要把服務端更新就能夠了。

版本控制通常用兩種方式

第一種：URL不變，版本寫在HTTP標頭內面。

第二種：版本寫在URL上面。

本人推薦第二種，比較直接方便了解。示例：

http://www.xxx.com/版本號

當前版本號：v1

http://www.baidu.com/v1/UserSecurity/Login

API風格

如今流行的api風格比較多，最出名的就是restful風格。

按本人的經驗，徹底走restful風格是很困難的，可能也是水平問題，在團隊內面也要考慮到其它成員的水平問題。咱們目前API風格仍是保留之前風格。

示例，V*表明版本號

http://xx.com/V*/UserSecurity/SignOut

HTTP謂詞

使用 Post 方法在服務器上建立/修改/刪除資源

使用 Get 方法從服務器檢索某個資源或者資源集合

基本命名規則

使用駱駝式命名法-大駝峯法

跨域處理

前端站點和後端API佈署到不一樣的站點，就會產生跨域問題。

什麼是同源策略？

同源是域名，協議，端口相同。也就是說若是不一樣，則是非同源。

同源策略是瀏覽器的一基本的安全功能，非同源訪問，瀏覽器會進行拒絕。

HMTL上面的SRC地址，你能夠指定任何URL，表單提交，你能夠提交到任何URL。

可是，你若是使用AJAX技術，就會受到同源策略的影響，拒絕提交。

現代瀏覽器幾乎都支持跨域資源請求的一種方式。這種技術叫CORS（跨域資源共享）

CORS跨域分兩種

第一種，簡單跨域。

第二種，複雜跨域。

解決方案：HTTP輸出標頭增長如何節點

注意有前端框架版本，對安全要求較高，不能使用通配符*，要指定跨域域名。

Access-Control-Allow-Origin：*

 

下面節點可填，可不填，根據實際狀況，自行決定。

1 2 3

Access-Control-Allow-Methods：GET,POST,OPTIONS Access-Control-Allow-Credentials： true Access-Control-Allow-Headers：根據請求頭的內容，填寫

　　

注意：複雜跨域比要簡單跨域麻煩，更花費性能。由於複雜跨域在請求以前會先發一個options預請求，根據響應判斷服務器是否支持跨域。也就是說，實際上請求了兩次。

Cookies做用域

不一樣的站點，如何通用Cookies?

通常狀況只需把cookies做用域設置頂級域名，瀏覽器會自動把cookies在訪問子域名的時候捎上去。

示例，訪問二級域名時候，cookies默認會被傳送過去。

頂級域名:baidul.com
cookies做用域：.baidu.com
二級域名：
www.baidu.com
api.baidu.com

 

示例

下面貼一些示例文檔，其它的就很少講啦

 

基本上，WebApi先後端分離的細節和注意點，都記錄下來，還有更多的細節，須要讀者在開發過程本身去尋找答案。隨筆完畢！