Java後端開發工做 - 寫接口

我在公司的工做內容是，對於一個BS應用，負責服務器端開發工做，Java語言。與前端開發人員合做，最終提供給前端RESTFUL接口，保證頁面正常響應。

經驗之談

一個接口能夠理解爲一個業務邏輯，一個業務邏輯能夠由1～n個SQL組成。一個優質的接口，應該是通用的接口，一旦需求變了，給過來的參數有變化，那我儘可能作到接口不變，你多給我一個參數或者某個參數變化一下，我就能夠給出你要的結果。

後端提供給前端的接口，要儘可能少。最好我給你一個接口，你能夠用這一個接口作不少事，拿不少數據。這樣對前端開發人員比較友好。後端開發人員對本身也要好一點，本身的mapper也要儘可能通用，service層封裝方法，幾個service給出的方法，最好都是一個mapper或者幾個mapper的組合。

寫接口的時候，要考慮到接口的服役期，不要寫一個簡單的接口，臨時使用。

舉個例子，企業帳戶充值的頁面，除了充值的功能外，原型上還有一個簡單的充值記錄查詢功能，只是查找當前企業的充值記錄。若是你的接口裏面，沒有將企業ID做爲搜索條件傳入，那麼恭喜你，你能夠準備好修改了。由於雖然短時期內，前端能夠調你這個接口取得數據，可是從此原型上增長了【充值記錄查詢】這個功能，用戶能夠輸入企業ID做爲搜索條件，你就要改接口了。你要改爲一個複雜一些的接口，在充值頁面中使用，也在充值記錄查詢這個頁面中使用，前端人員還得修改充值頁面中調用的接口。這是典型的先甜後苦的狀況。

爲了前端和後端能夠並行開發，後端開發人員應該先在RAP中定義接口並告知前端，前端開發人員就能夠根據接口URL和參數，綁定到頁面的觸發函數中。

並行開發帶來效率的提高的，可是難點是要預先籌劃好接口，而且在後來的開發過程當中儘可能保證不變，特別是數組之類的數據結構不要修改，不然前端遍歷處理的修改將會很麻煩。

要作到這樣，就須要一些後端接口開發的經驗，並且提早計劃老是比較困難的，就像敏捷開發中的 Sprint Planning 老是比較難完成。可是堅持這麼作，對本身的能力也是一種激勵和提高，所以推薦這麼作。

返回類和分頁

返回給前端的數據，須要有Response類/ResponsePages類封裝，也就是要帶有返回碼，返回消息和返回體。若是要求給出分頁信息，那麼ResponsePages類中，還須要有Page類，其中至少包括當前頁數，每頁顯示條數和總條數信息。分頁使用github的pagehelper工具類來完成。

返回碼

返回碼不可使用http狀態碼，由於http狀態碼是有限的，並且提示信息很模糊，不足以定義豐富的業務錯誤，所以要定義本身的業務返回碼。一樣，也要成對定義業務返回消息，用於描述業務錯誤。業務分配的錯誤編碼表，須要由研發部門統籌給出。若是是服務之間調用的，應當透傳返回碼和返回消息。

http返回對象：
{
    code: code,
    msg: msg,
    pageInfo: {         // 分頁信息
        curPage: 1,
        pageLimit: 10,
        page: 1,
        total: 10
    }
    data: {data}
}

 

服務之間通訊

服務和服務之間調用，經過RPC接口，通常分爲【api模塊】和【provider模塊】。服務的治理採用微服務框架。服務有服務名稱，服務組別和服務的版本號。 RPC的框架，2017年使用的是阿里的HSF框架，也就是Pandora容器。2018年10月開始，逐步轉成幟訊RPC框架這是一種封裝了Dubbo的RPC框架。目前正在進行架構改造。 微服務的架構下，服務部署在不一樣的服務器中，它們所對應的數據庫也是不一樣的。有的時候，數據須要聯查才能夠組裝，這就要考慮網絡通訊的代價。通常的作法，一次性從他處拿到數據，組裝成map或者mapList，而後再與本地的數據作匹配。注意map或者mapList要儘可能小。

HSF框架

HSF框架，服務的提供者具備@HSFProvider註解，服務的消費者具備@HSFConsumer註解，二者都會註冊到【EDAS Config Center】註冊中心，該註冊中心負責服務的註冊與發現，以及配置中心。每一個服務都有Group，DataId和Version。若是在同一網段有兩個Group、DataId和Version都相同的服務同時啓動，那麼註冊中心就會進行隨機調度。

幟訊RPC框架

幟訊RPC框架是封裝了Dubbo的RPC框架，支持服務治理的框架參數化傳入，能夠是dubbo，也能夠是市場上的任何一種RPC框架。目前默認是Dubbo。 具體來講，服務的提供者使用【@FlaginfoProvider】註解，服務的消費者使用【@FlaginfoConsumer】註解，服務組，服務名和版本號暫時不須要傳入。注意，若是要標記提供者，不能夠同時使用【@FlaginfoProvider】和【@Service】標籤，不然會出現尋找實例化bean超過一個的錯誤。

 

咱們來看一下RPC服務的代碼結構，分爲【api】和【provider】，簡單來講，【api】中定義了暴露給其餘服務的接口，【provider】中的內容是接口的實現。團隊協做開發的時候，當你提交新的接口，而接口jar包版本又不升級的時候，須要記得把接口實現的代碼一併提交。若是接口實現負責，一時間沒法完成，那麼能夠先提交一個空的實現。若是你不這麼作，那麼當團隊其餘成員嘗試發佈RPC服務的時候，就會報【接口沒有實現】的編譯錯誤，影響發佈。

開發雜談

RAP必定要好好使用。在寫接口以前，最好先定義好RAP，包括URL，入參和返回，這樣前端開發人員就能夠根據RAP去寫前端頁面，而同時後端人員能夠實現這個接口。後端開發過程當中，注意RAP上定義好的內容儘可能不要變動。

 

 

關於枚舉類，推薦使用Enum類來處理，好處是一次定義，多處使用，缺點是代碼量增長，並且前端後端轉換過程當中要注意處理空值的狀況。

通常，前端發起一個POST請求，傳過來的參數是JSON格式的，後端使用Spring的【@RequestBody】註解將其轉換成Java類，通常是一個VO。後端使用service處理之後，返回的是【@ResponseBody】類型的數據，這樣前端拿到後自動會解析成JSON格式的數據。 以上是最基本的數據類型和標籤使用，還有例如【@RestController】【@PostMapping】等，能夠參看【Spring RESTful接口經常使用註解】。

持久層框架

後端和前端的交互，通常都是要從數據庫中取出數據，而後在前端頁面渲染。所以，後端寫接口，很重要的一點，就是去數據庫中取數據。幟訊使用的ORM框架是輕量級的MyBatis，DTO，mapper interface和xml文件，經過 MyBatis Generator自動生成。

下面來講說 MyBatis 的 xml文件。該文件能夠接收VO，這樣就能夠直接接收前端傳過來的參數。xml文件返回的通常是DTO，通常是DTO的List，注意調interface後要用一個List來組裝。xml文件的核心是SQL語句，用於從數據庫中取出數據。若是沒有把握，能夠將SQL語句在Navicat中執行一遍，看看輸出的結果。

知識總結

個人認知中，簡單地把【RESTFul接口/調用方式】理解爲前端能夠調用的，後端也能夠經過httpClient的方式向其餘服務的URL發送請求，獲取數據；【RPC接口/調用方式】是服務之間的相互調用，前端沒法直接使用。 前者經過Controller暴露出接口，前端訪問URL，同時帶上參數，如此來使用後端的服務；後者分api和provider，api暴露出接口，消費者引用提供者的api來調用。

 

創做日期：03/10/2018 21:32