目前前端同后端的合作方式是前后端分離，通過Nginx+Tomcat的組合部署(還可加nodejs中間件)方式能有效的進行解耦，并且前后端分離為項目以后的架構(gòu)擴展、微服務化、組件化都打下重要基礎,所以這在以后是一個發(fā)展的必然趨勢,我們需要去適應,做出改變！??！ 早期的開發(fā)方式 早期的開發(fā)方式如下圖： 前后端分離的探索 jsonp 可能由于我在前面三年積累了豐富的前端經(jīng)驗,在上家公司主要負責開發(fā)官網(wǎng)、微信、后臺等相關(guān)系統(tǒng)的接口，前期我們的開發(fā)方式雖然也是前后端分離的方式,但大都使用jsonp跨域接口調(diào)用的方式來達到分離效果,后端所有的接口都是可跨域調(diào)用的jsonp形式,拋開需要登錄的授權(quán)之外的接口，前端在開發(fā)的時候本地無需開啟服務即可調(diào)用服務端接口，然后渲染數(shù)據(jù)，完成頁面交互渲染效果 jsonp的優(yōu)點
jsonp的原理其實很簡單，當然,這也涉及到前端的知識,簡單點說就是js端的function函數(shù)執(zhí)行 正常的后端響應數(shù)據(jù),例如： { 'code':'8200', 'data':{ 'id':'100', 'name':'Test' //more...... }} jsonp需要的返回格式： callback({ 'code':'8200', 'data':{ 'id':'100', 'name':'Test' //more...... }}); 前端在頁面定義callback回調(diào)函數(shù),callback函數(shù)接收后端響應回來的data-json數(shù)據(jù),后端響應后執(zhí)行callback函數(shù)達到調(diào)用前端業(yè)務邏輯的目的,渲染頁面 nginx+ajax 這種配合開發(fā)方式也是適合前端還沒有引入Node等一站式開發(fā)解決方案的情況下引入的,純粹的HTML+CSS+JS同后端對接，綁定業(yè)務接口,渲染數(shù)據(jù) 我們在使用JSONP開發(fā)的時候,前端都是需要在頁面端寫死HOST+IP接口地址,存在很重大一個弊端就是前端需要些config文件，來配置我們后端的接口請求地址，如果前端工程師規(guī)范意識強一點，會通用到一個配置文件里，但是如果沒有這方面的意識的話，就會出現(xiàn)代碼里硬編碼的情況，不利于服務器遷移，代碼更新，接口變動等操作 為規(guī)避上面碰到的問題,使用nginx的反向代理功能,將后端服務器代理下來,前端在開發(fā)的時候本地開啟nginx服務，即解決了jsonp跨域問題,同時也解決了無需寫死后端的服務ip+端口地址，利于后端在部署時整合代碼,減少不必要的錯誤 node 隨著NodeJs的火熱,前端已經(jīng)可以本地開啟服務寫接口的情況下,就類似服務端開啟tomcat一樣,在這樣的情況下，前端框架VUE、React等都在此基礎上,提供了一套完整的技術(shù)解決方案，這和上面說到的開啟nginx服務架構(gòu)有點類似 這樣做的意義：真正的解放了前后端，專注各自擅長的領域 技術(shù)架構(gòu)如下： 前端node服務直接訪問后端Java Restful Api接口服務，Api接口最終訪問數(shù)據(jù)庫完成數(shù)據(jù)查詢最終返回node層，node渲染響應數(shù)據(jù)到前端 如果存在會話信息同步等問題，可以使用中間件,例如redis緩存數(shù)據(jù)庫,解決前端node和后端Api信息同步問題，傳參可以通過JWT等方式完成接口權(quán)限驗證 不管是jsonp還是ajax+nginx這兩種方式,node作為中間件都可以輕松切換處理,而且node作為中間層,還可以將多個后端接口組合成一整個數(shù)據(jù)集,最終以同步的方式渲染前端,這也利于做SEO優(yōu)化,也是前面兩種方式無法做到的 關(guān)于前后端分離,詳細可閱讀前后端分離的思考與實踐,該文章詳細的列述了關(guān)于前后端分離的實際經(jīng)驗 談談接口 隨著前后端的分離,后端工程師不需要編寫頁面，不需要寫JS,只需要提供接口即可,可是就是僅僅這一個接口，對于很多后端開發(fā)工程師而言，在實際開發(fā)，同前端對接的過程中,依然問題重重 很多后端同學說我只負責寫接口,其他我一概不管,這樣造成的后果就是 1、接口結(jié)構(gòu)無序、雜亂無章 2、接口和實際業(yè)務場景不相匹配、不可用 3、頻繁的同前端溝通，簡單的事情復雜化,前后端都很惱火 4、事情沒做好 后端在編寫接口前,首先是對業(yè)務的理解,在對業(yè)務未理解透徹之前,編碼都是無意義的,作為后端來說,需要鍛煉自己對整個系統(tǒng)全局考慮的能力,接口之間并非是毫無關(guān)聯(lián)的,我們在寫第一個接口之間,其他接口之間的業(yè)務邏輯也許考慮到，這在后端團隊合作開發(fā)不同功能的情況下顯得尤為重要. 后端在開發(fā)接口時,我覺得主要從以下幾個方面需要注意：
接口url定義 對于后端開發(fā)人員來說,接口前端入?yún)?最終組合查詢數(shù)據(jù)庫資源，經(jīng)過一系列相關(guān)業(yè)務場景下的計算，響應給前端json數(shù)據(jù)，每一層url的path定義需要清晰明了，這和后端在使用AOP定義事務管理同理，后端service需要滿足一定的命名規(guī)范，這樣方便統(tǒng)一管理，而且有這層規(guī)范后,后續(xù)的前后端對接會輕松很多 為了在許多API和長時間內(nèi)提供一致的開發(fā)人員體驗，API使用的所有名稱應為：
這包括接口，資源，集合，方法和消息的名稱。 由于許多開發(fā)人員不是英文母語人士，因此這些命名約定的目標之一是確保大多數(shù)開發(fā)人員能夠輕松了解API。 它通過鼓勵在命名方法和資源時使用簡單，一致和小的詞匯表來實現(xiàn)。
接口類型、參數(shù) 關(guān)于接口的請求類型，目前比較常用的：GET、POST、PUT、DELETE、PATCH
后端可根據(jù)不同的業(yè)務場景定義不同的接口類型 在定義接口參數(shù)之時,目前我們常用的幾種提交方式 表單提交，application/x-www-form-urlencoded 表單提交主要針對key-value的提交形式 如下Java片段： @PostMapping('/queryAll')public RestfulMessage queryAll(RuleCheckLogs ruleCheckLogs, @RequestParam(value = 'current_page',defaultValue = '1')Integer current_page , @RequestParam(value = 'page_size',defaultValue = '10')Integer page_size , @RequestParam(value = 'tableName',required = false) String tableName){ RestfulMessage restfulMessage=new RestfulMessage(); try{ assertArgumentNotEmpty(ruleCheckLogs.getProjectId(),'質(zhì)檢方案id不能為空'); restfulMessage.setData(qcRuleCheckLogsService.queryRuleLogsByPage(ruleCheckLogs,tableName,current_page,page_size)); }catch (Exception e){ restfulMessage=wrapperException(e); } return restfulMessage;} 文件流提交 json提交,application/json json提交方式在SpringMVC或Spring Boot中主要有兩種,一種是以@RequestBody注解接收方式，另外一種是以HttpEntity Java代碼示例： 全局錯誤碼定義 錯誤碼的定義同HTTP請求狀態(tài)碼一樣,對接者能通過系統(tǒng)定義的錯誤碼,快速了解接口返回錯誤信息，方便排查錯誤原因 接口json格式 后端響應json給前端需要注意以下幾點： 1、json格式需固定 例如如下圖形 如上圖所示,橫向是時間,縱向是value值 我們給出的json結(jié)構(gòu)應該如此： 在工作中,我們經(jīng)常碰見這樣的數(shù)據(jù)格式： 這里所說的json格式固定主要針對此種情況,后端給到前端的接口格式必須是固定的，所有動態(tài)數(shù)據(jù)值都需相應的key與之對應 2、所有返回接口數(shù)據(jù)需直接可用,越簡單越好 后端提供給前端的接口數(shù)據(jù),最終交給前端的工作，只需要讓前端渲染數(shù)據(jù)即可,越簡單越好，不因摻雜過多的業(yè)務邏輯讓前端處理，所有復雜的業(yè)務邏輯，能合并規(guī)避掉的都需后端處理掉. 接口文檔編寫 接口文檔編寫是前后端對接重要依據(jù)，后端寫明接口文檔，前端根據(jù)接口文檔對接 文檔形勢目前主要分幾種： 1、依賴swagger框架，自動生成接口文檔（swagger只能生成基于key-value詳細參數(shù)方式，針對json格式，無法說明具體請求內(nèi)容） 2、手動編寫說明文檔，推薦markdown編寫 接口對接 萬事俱備,只欠東風,雖然上面我們準備了所有我們該準備的，接口定義完美無缺,接口文檔也已說明，但在對接時任然可能出現(xiàn)問題，此時我想我們還需注意的細節(jié) 1、后端接口需自行進行Junit單元測試 Spring目前集成Junit框架可方便進行單元測試，包括對業(yè)務bean的方法測試，以及針對api的mock測試 2、使用工具測試，推薦PostMan 作為接口調(diào)試神器,Postman大名想必大家都已知道 作為后端來說,我們需要學會查看chrome推薦給我們的審查元素的功能，可參看Chrome開發(fā)工具介紹 chrome提供了一個可以copy當前接口的url功能，最終生成curl命令行 最終通過Copy as cURL(bash)功能可生成curl命令 以上命令可以在Linux等各終端直接執(zhí)行 curl命令是一個利用URL規(guī)則在命令行下工作的文件傳輸工具。它支持文件的上傳和下載，所以是綜合傳輸工具，但按傳統(tǒng)，習慣稱curl為下載工具。作為一款強力工具，curl支持包括HTTP、HTTPS、ftp等眾多協(xié)議，還支持POST、cookies、認證、從指定偏移處下載部分文件、用戶代理字符串、限速、文件大小、進度條等特征。做網(wǎng)頁處理流程和數(shù)據(jù)檢索自動化，curl可以祝一臂之力。 postman提供導入curl命令行 前后端分離,簡化了我們的開發(fā)方式,不同人專注于不同的領域,技術(shù)價值最大化,大大提高工作效率,我們在掌握這些技能的同時,也需要加強自身的發(fā)展,以適應當前的技術(shù)發(fā)展趨勢,不管是前端還是后端,多了解一些。 這些技術(shù)如何學習，有沒有免費資料？ 對前端的技術(shù)，架構(gòu)技術(shù)感興趣的同學關(guān)注我的頭條號，并在后臺私信發(fā)送關(guān)鍵字：“前端”即可獲取免費的架構(gòu)師學習資料 知識體系已整理好，歡迎免費領取。還有面試視頻分享可以免費獲取。關(guān)注我，可以獲得沒有的架構(gòu)經(jīng)驗哦！！ |
|
|
