前端與後臺對接的思考與總結
隨著前端NodeJs技術的火爆,現在的前端已經非以前傳統意義上的前端了,各種前端框架(Vue、React、Angular......)井噴式發展,配合NodeJs服務端渲染引擎,目前前端能完成的工作不僅僅侷限於CSS，JS等方面，很多系統的業務邏輯都可以放在前端來完成。
那可能有些人會說,前端這麼火,NodeJs發展這麼迅猛,後端是不是以後都沒事情幹了，其實不然,拿Java來說，經過這麼多年發展,已經相當穩定,完善的生態圈也非最近今年發展起來的NodeJs可比，我們常常說聞道有先後，術業有專攻,用在這裡最合適不過了，叢集、分散式、高可用等等技術還是需要後端架構師來思考的事情
目前前端同後端的合作方式是前後端分離，通過Nginx+Tomcat的組合部署(還可加nodejs中介軟體)方式能有效的進行解耦，並且前後端分離為專案以後的架構擴充套件、微服務化、元件化都打下重要基礎,所以這在以後是一個發展的必然趨勢,我們需要去適應,做出改變！
相信有很多想學前端的小夥伴，今年年初我花了一個月整理了一份最適合2018年學習的web前端乾貨，從最基礎的HTML+CSS+JS到移動端HTML5到各種框架都有整理，送給每一位前端小夥伴，731771211
早期的開發方式
早期的開發方式如下圖：
這也是我前面工作1-3年的開發方式,我們沒有前端幫我們寫JS函式功能,所有的頁面表單驗證,資料渲染,資料介面編寫都是我們後端全部實現,看上去更像是一個全棧工程師,從需求分析、搭建整個技術架構、資料庫表設計、功能設計、編碼開發，再到最終部署上線,我們無所不在,這可能也是目前很多小公司仍然在沿用的開發方式,很多後端同學擔負起了專案的方方面面
以我目前的經驗來看,這樣的開發方式對我個人的成長是有益無害的,因為你只有在瞭解了前端的JS/CSS/HTML的情況下,然後再談目前的前後端分離,會讓你的工作事半功倍,在寫後端介面前,你腦子裡浮現的是整個功能的互動頁面,最終呈現的是前後端合作開發好後的的終端結果,這大大縮減了前後端的溝通交流
前後端分離的探索
jsonp
可能由於我在前面三年積累了豐富的前端經驗,在上家公司主要負責開發官網、微信、後臺等相關係統的介面，前期我們的開發方式雖然也是前後端分離的方式,但大都使用jsonp跨域介面呼叫的方式來達到分離效果,後端所有的介面都是可跨域呼叫的jsonp形式,拋開需要登入的授權之外的介面，前端在開發的時候本地無需開啟服務即可呼叫服務端介面，然後渲染資料，完成頁面互動渲染效果
jsonp的優點
不像XMLHttpRequest物件實現的Ajax請求那樣受到同源策略的限制
相容性更好,在更低版本的ie瀏覽器中都能相容,這裡區別於cors跨域型別
jsonp的原理其實很簡單，當然,這也涉及到前端的知識,簡單點說就是js端的function函式執行
正常的後端響應資料,例如：
jsonp需要的返回格式：
前端在頁面定義callback回撥函式,callback函式接收後端響應回來的data-json資料,後端響應後執行callback函式達到呼叫前端業務邏輯的目的,渲染頁面
nginx+ajax
這種配合開發方式也是適合前端還沒有引入Node等一站式開發解決方案的情況下引入的,純粹的HTML+CSS+JS同後端對接，繫結業務介面,渲染資料
我們在使用JSONP開發的時候,前端都是需要在頁面端寫死HOST+IP介面地址,存在很重大一個弊端就是前端需要些config檔案，來配置我們後端的介面請求地址，如果前端工程師規範意識強一點，會通用到一個配置檔案裡，但是如果沒有這方面的意識的話，就會出現程式碼裡硬編碼的情況，不利於伺服器遷移，程式碼更新，介面變動等操作
為規避上面碰到的問題,使用nginx的反向代理功能,將後端伺服器代理下來,前端在開發的時候本地開啟nginx服務，即解決了jsonp跨域問題,同時也解決了無需寫死後端的服務ip+埠地址，利於後端在部署時整合程式碼,減少不必要的錯誤
node
隨著NodeJs的火熱,前端已經可以本地開啟服務寫介面的情況下,就類似服務端開啟tomcat一樣,在這樣的情況下，前端框架VUE、React等都在此基礎上,提供了一套完整的技術解決方案，這和上面說到的開啟nginx服務架構有點類似
這樣做的意義：真正的解放了前後端，專注各自擅長的領域
技術架構如下：
前端node服務直接訪問後端Java Restful Api介面服務，Api介面最終訪問資料庫完成資料查詢最終返回node層，node渲染響應資料到前端
如果存在會話資訊同步等問題，可以使用中介軟體,例如redis快取資料庫,解決前端node和後端Api資訊同步問題，傳參可以通過 JWT 等方式完成介面許可權驗證
不管是jsonp還是ajax+nginx這兩種方式,node作為中介軟體都可以輕鬆切換處理,而且node作為中間層,還可以將多個後端介面組合成一整個資料集,最終以同步的方式渲染前端,這也利於做SEO優化,也是前面兩種方式無法做到的
介面
隨著前後端的分離,後端工程師不需要編寫頁面，不需要寫JS,只需要提供介面即可,可是就是僅僅這一個介面，對於很多後端開發工程師而言，在實際開發，同前端對接的過程中,依然問題重重
很多後端同學說我只負責寫介面,其他我一概不管,這樣造成的後果就是
1、介面結構無序、雜亂無章
2、介面和實際業務場景不相匹配、不可用
3、頻繁的同前端溝通，簡單的事情複雜化,前後端都很惱火
4、事情沒做好
後端在編寫介面前,首先是對業務的理解,在對業務未理解透徹之前,編碼都是無意義的,作為後端來說,需要鍛鍊自己對整個系統全域性考慮的能力,介面之間並非是毫無關聯的,我們在寫第一個介面之間,其他介面之間的業務邏輯也許考慮到，這在後端團隊合作開發不同功能的情況下顯得尤為重要.
後端在開發介面時,我覺得主要從以下幾個方面需要注意：
介面url 定義
介面型別、引數
全域性錯誤碼定義
介面json格式
介面文件編寫
介面url定義
對於後端開發人員來說,介面前端入參,最終組合查詢資料庫資源，經過一系列相關業務場景下的計算，響應給前端json資料，每一層url的path定義需要清晰明瞭，這和後端在使用AOP定義事務管理同理，後端service需要滿足一定的命名規範，這樣方便統一管理，而且有這層規範後,後續的前後端對接會輕鬆很多
為了在許多API和長時間內提供一致的開發人員體驗，API使用的所有名稱應為：
簡單
直覺
一致
這包括介面，資源，集合，方法和訊息的名稱。
由於許多開發人員不是英文母語人士，因此這些命名約定的目標之一是確保大多數開發人員能夠輕鬆瞭解API。 它通過鼓勵在命名方法和資源時使用簡單，一致和小的詞彙表來實現。
API中使用的名稱應該是正確的美國英語。例如，許可證（而不是許可證），顏色（而不是顏色）。
可以簡單地使用常用的簡短形式或長字的縮寫。例如，API優於應用程式程式設計介面。
儘可能使用直觀，熟悉的術語。例如，當描述刪除（和銷燬）資源時，刪除是優先於擦除。
對同一概念使用相同的名稱或術語，包括跨API共享的概念。
避免名稱過載。為不同的概念使用不同的名稱。
仔細考慮使用可能與常用程式語言中的關鍵字衝突的名稱。可以使用這些名稱，但在API審查期間可能會觸發額外的審查。謹慎和謹慎地使用它們。
介面型別、引數
關於介面的請求型別，目前比較常用的：GET、POST、PUT、DELETE、PATCH
GET（SELECT）：從伺服器取出資源（一項或多項）。 POST（CREATE）：在伺服器新建一個資源。 PUT（UPDATE）：在伺服器更新資源（客戶端提供改變後的完整資源）。 PATCH（UPDATE）：在伺服器更新資源（客戶端提供改變的屬性）。 DELETE（DELETE）：從伺服器刪除資源。
後端可根據不同的業務場景定義不同的介面型別
在定義介面引數之時,目前我們常用的幾種提交方式
表單提交，application/x-www-form-urlencoded
表單提交主要針對key-value的提交形式
如下Java片段：
檔案流提交
json提交,application/json
json提交方式在SpringMVC或Spring Boot中主要有兩種,一種是以@RequestBody註解接收方式，另外一種是以HttpEntity<String> requestEntity位元組接收
Java程式碼示例：
全域性錯誤碼定義
錯誤碼的定義同HTTP請求狀態碼一樣,對接者能通過系統定義的錯誤碼,快速瞭解介面返回錯誤資訊，方便排查錯誤原因
介面json格式
後端響應json給前端需要注意以下幾點：
1、json格式需固定
例如如下圖形
如上圖所示,橫向是時間,縱向是value值
我們給出的json結構應該如此：
在工作中,我們經常碰見這樣的資料格式：
這裡所說的json格式固定主要針對此種情況,後端給到前端的介面格式必須是固定的，所有動態資料值都需相應的key與之對應
2、所有返回介面資料需直接可用,越簡單越好
後端提供給前端的介面資料,最終交給前端的工作，只需要讓前端渲染資料即可,越簡單越好，不因摻雜過多的業務邏輯讓前端處理，所有複雜的業務邏輯，能合併規避掉的都需後端處理掉.
介面文件編寫
介面文件編寫是前後端對接重要依據，後端寫明介面文件，前端根據介面文件對接
文件形勢目前主要分幾種：
1、依賴swagger框架，自動生成介面文件（swagger只能生成基於key-value詳細引數方式，針對json格式，無法說明具體請求內容）
2、手動編寫說明文件，推薦markdown編寫
介面對接
萬事俱備,只欠東風,雖然上面我們準備了所有我們該準備的，介面定義完美無缺,介面文件也已說明，但在對接時任然可能出現問題，此時我想我們還需注意的細節
1、後端介面需自行進行Junit單元測試
Spring目前整合Junit框架可方便進行單元測試，包括對業務bean的方法測試，以及針對api的mock測試
2、使用工具測試，推薦PostMan
作為介面除錯神器,Postman大名想必大家都已知道
作為後端來說,我們需要學會檢視chrome推薦給我們的審查元素的功能，
chrome提供了一個可以copy當前介面的url功能，最終生成curl命令列
最終通過Copy as cURL(bash)功能可生成curl命令
以上命令可以在Linux等各終端直接執行
curl命令 是一個利用URL規則在命令列下工作的檔案傳輸工具。它支援檔案的上傳和下載，所以是綜合傳輸工具，但按傳統，習慣稱curl為下載工具。作為一款強力工具，curl支援包括HTTP、HTTPS、 ofollow,noindex">ftp 等眾多協議，還支援POST、cookies、認證、從指定偏移處下載部分檔案、使用者代理字串、限速、檔案大小、進度條等特徵。做網頁處理流程和資料檢索自動化，curl可以祝一臂之力。
postman提供匯入curl命令列
3、前後端需心平氣和溝通，勿推卸責任，前後端開發人員水平不盡相同,作為同事,需要的是團結合作，努力將事情做好,而非相互推卸
結語
前後端分離,簡化了我們的開發方式,不同人專注於不同的領域,技術價值最大化,大大提高工作效率,我們在掌握這些技能的同時,也需要加強自身的發展,以適應當前的技術發展趨勢。
如果你依然在程式設計的世界裡迷茫，不知道自己的未來規劃，對前端感興趣，可以加入前端學習交流群：731771211 裡面可以與大神一起交流並走出迷茫。小白可進群免費領取學習資料，看看前輩們是如何在程式設計的世界裡傲然前行。