實作前後端分離 servlet_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

具體異常

這是一個有點争議的地方，有很多業務邏輯異常，出于對使用者的友好提示。一些生澀難懂的錯誤提示，直接給到使用者，使用者一臉懵逼。但是後端卻不能修改成友好提示，這樣不友善調試，尋找問題原因。

一般來講，前端可以自動修改友好提示給使用者。

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

建議：盡量使用異常代碼，大家可以看到上面貼出例子，就使用的異常代碼。每種異常都有唯一編号，描述可以更改。但是編号不變。

版本控制

每個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：*
           

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

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

注意：複雜跨域比要簡單跨域麻煩，更花費性能。因為複雜跨域在請求之前會先發一個options預請求，根據響應判斷伺服器是否支援跨域。也就是說，實際上請求了兩次。Cookies作用域

不同的站點，如何通用Cookies?

一般情況隻需把cookies作用域設定頂級域名，浏覽器會自動把cookies在通路子域名的時候捎上去。

示例，通路二級域名時候，cookies預設會被傳送過去。

頂級域名:baidu.com
cookies作用域：.baidu.com
二級域名：api.baidu.com
           

示例

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