【API規範】聊聊先後端分離接口規範

前言

在移動互聯網，分佈式、微服務盛行的今天，先後端的工做職責愈來愈明確，前端頁面的展現、交互體驗愈來愈靈活、炫麗，響應體驗也要求愈來愈高，後端服務的高併發、高可用、高性能、高擴展等特性的要求也越發苛刻，而帶來的另外一個問題：先後端的對接界面雙方卻關注甚少，沒有任何接口約定規範狀況下各自幹各自的，致使咱們在產品項目開發過程當中，先後端的接口聯調對接工做量佔比在30%-50%左右，甚至會更高。

爲什麼要分離

前端開發重度依賴開發環境，開發效率低。

前端工程師作html頁面，寫好後，後端工程師將html頁面套成jsp頁面，好處很明顯，能夠本地開發，很高效，但若是html發生變動，那你就慘了，並且模板是後端套的，頗有可能套錯，套完後還須要前端肯定，來回溝通調整的成本比較大。

先後端職責依舊糾纏不清。

之前的JavaWeb項目大多數都是java程序員又當爹又當媽，又搞前端，又搞後端。

大多數項目都是MVC架構，控制層，業務層，持久層。控制層負責接收參數，調用相關業務層，封裝數據，以及路由&渲染到jsp頁面，但前端要是弱勢一點，每每就會被後端要求在模板層寫出很多業務代碼,還有一個很大的灰色地帶是 Controller，頁面路由等功能本應該是前端最關注的，但倒是由後端來實現。Controller 自己與 Model 每每也會糾纏不清，看了讓人咬牙的業務代碼常常會出如今 Controller 層。這些問題不能全歸結於程序員的素養，不然 JSP 就夠了。

先後分離的優點

1. 實現真正的先後端解耦，前端服務器使用nginx，前端/WEB服務器放的是css，js，圖片等等一系列靜態資源（甚至你還能夠css，js，圖片等資源放到特定的文件服務器，例如阿里雲的oss，並使用cdn加速）
2. 發現bug，能夠快速定位是誰的問題，不會出現互相踢皮球的現象。
3. 減小後端服務器的併發/負載壓力。除了接口之外的其餘全部http請求所有轉移到前端nginx上，接口的請求調用tomcat，參考nginx反向代理tomcat。
4. 即便後端服務暫時宕機了，前端頁面也能夠正常訪問，只不過看不到數據。
5. nginx支持頁面熱部署，不用重啓服務器，前端升級更無縫。
6. 增長代碼的可維護性，先後端耦在一塊兒的代碼維護成本很高。
7. 在nginx中部署證書，外網使用https訪問，而且只開放443和80端口，其餘端口一概關閉，內網使用http，性能和安全都有保障。

如何作分離

分離職責

先後端僅經過異步接口來編程，先後端都各自有本身的開發流程，構建工具，測試集合。

開發流程

1. 先後端約定接口&數據&參數
2. 先後端並行開發（前端根據接口文檔進行開發 + Mock平臺）
3. 開發完成後聯調和提交測試

Mock 服務器根據接口文檔自動生成 Mock 數據，實現了接口文檔即API：

接口規範

規範原則

1. 接口返回數據即顯示：前端僅作渲染邏輯處理
2. 渲染邏輯禁止跨多個接口調用
3. 前端關注交互、渲染邏輯，儘可能避免業務邏輯處理的出現
4. 請求響應傳輸數據格式：JSON，JSON數據儘可能簡單輕量，避免多級JSON的出現

基本格式

請求格式

get

user/login?body={"uname":"root","pwd":"root"}
複製代碼

post

返回格式

{
  code:200,        //返回狀態碼
  message:'請求成功',  //返回信息描述
  data:object  //返回值
}
複製代碼

CODE狀態碼

• 200 - 請求成功
• 301 - 資源（網頁等）被永久轉移到其它URL
• 404 - 請求的資源（網頁等）不存在
• 500 - 內部服務器錯誤