<font id="zqva1"></font>
<rt id="zqva1"></rt>
  • <tt id="zqva1"></tt>
    <cite id="zqva1"></cite>

    <cite id="zqva1"><noscript id="zqva1"></noscript></cite>
      <rp id="zqva1"><meter id="zqva1"></meter></rp>

        <cite id="zqva1"></cite>
          <b id="zqva1"></b>
          <rp id="zqva1"></rp>
          <cite id="zqva1"></cite>

          <rt id="zqva1"></rt>

        1. <rp id="zqva1"></rp>

          web開發,前后分離接口規范

          時間:?2017-12-06閱讀:?3688標簽:?規范

          1. 前言

          隨著互聯網的高速發展,前端頁面的展示、交互體驗越來越靈活、炫麗,響應體驗也要求越來越高,后端服務的高并發、高可用、高性能、高擴展等特性的要求也愈加苛刻,從而導致前后端研發各自專注于自己擅長的領域深耕細作。

          然而帶來的另一個問題:前后端的對接界面雙方卻關注甚少,沒有任何接口約定規范情況下各自擼起袖子就是干,導致我們在產品項目開發過程中,前后端的接口聯調對接
          工作量占比在30%-50%左右,甚至會更高。往往前后端接口聯調對接及系統間的聯調對接都是整個產品項目研發的軟肋。

          本文的主要初衷就是規范約定先行,盡量避免溝通聯調產生的不必要的問題,讓大家身心愉快地專注于各自擅長的領域。


          2. 為何要分離

          參考兩篇文章《Web 研發模式的演變》《Web應用的組件化開發》, 目前現有前后端開發模式:“后端為主的MVC時代”,如下圖所示:


          后端為主的MVC時代

          代碼可維護性得到明顯好轉,MVC 是個非常好的協作模式,從架構層面讓開發者懂得什么代碼應該寫在什么地方。為了讓 View 層更簡單干脆,還可以選擇 Velocity、Freemaker 等模板,使得模板里寫不了 Java 代碼。看起來是功能變弱了,但正是這種限制使得前后端分工更清晰。然而依舊并不是那么清晰,這個階段的典型問題是:

          前端開發重度依賴開發環境,開發效率低。這種架構下,前后端協作有兩種模式:一種是前端寫demo,寫好后,讓后端去套模板 。淘寶早期包括現在依舊有大量業務線是這種模式。好處很明顯,demo 可以本地開發,很高效。不足是還需要后端套模板,有可能套錯,套完后還需要前端確定,來回溝通調整的成本比較大。另一種協作模式是前端負責瀏覽器端的所有開發和服務器端的 View 層模板開發,支付寶是這種模式。 好處是 UI 相關的代碼都是前端去寫就好,后端不用太關注,不足就是前端開發重度綁定后端環境,環境成為影響前端開發效率的重要因素。

          前后端職責依舊糾纏不清。 Velocity 模板還是蠻強大的,變量、邏輯、宏等特性,依舊可以通過拿到的上下文變量來實現各種業務邏輯。這樣,只要前端弱勢一點,往往就會被后端要求在模板層寫出不少業務代碼。還有一個很大的灰色地帶是 Controller,頁面路由等功能本應該是前端最關注的,但卻是由后端來實現。 Controller 本身與 Model 往往也會糾纏不清,看了讓人咬牙的業務代碼經常會出現在 Controller 層。這些問題不能全歸結于程序員的素養,否則 JSP 就夠了。

          對前端發揮的局限。 性能優化如果只在前端做空間非常有限,于是我們經常需要后端合作才能碰撞出火花,但由于后端框架限制,我們很難使用CometBigpipe等技術方案來優化性能。

          總上所述,就跟為什麼要代碼重構一樣:

          關注點分離

          職責分離

          對的人做對的事

          更好的共建模式

          快速的反應變化


          3. 什么是分離

          我們現在要做的前后分離第一階段:“基于 Ajax 帶來的 SPA 時代”,如圖:


          基于 Ajax 帶來的 SPA 時代

          這種模式下,前后端的分工非常清晰,前后端的關鍵協作點是 Ajax 接口。 看起來是如此美妙,但回過頭來看看的話,這與 JSP 時代區別不大。復雜度從服務端的 JSP 里移到了瀏覽器的 JavaScript,瀏覽器端變得很復雜。類似 Spring MVC,這個時代開始出現瀏覽器端的分層架構:


          瀏覽器端的分層架構

          對于這一SPA階段,前后端分離有幾個重要挑戰:

          前后端接口的約定。 如果后端的接口一塌糊涂,如果后端的業務模型不夠穩定,那么前端開發會很痛苦。這一塊在業界有 API Blueprint 等方案來約定和沉淀接口,==在阿里,不少團隊也有類似嘗試,通過接口規則、接口平臺等方式來做。有了和后端一起沉淀的接口規則,還可以用來模擬數據,使得前后端可以在約定接口后實現高效并行開發。== 相信這一塊會越做越好。

          前端開發的復雜度控制。 SPA 應用大多以功能交互型為主,JavaScript 代碼過十萬行很正常。大量 JS 代碼的組織,與 View 層的綁定等,都不是容易的事情。典型的解決方案是業界的 Backbone,但 Backbone 做的事還很有限,依舊存在大量空白區域需要挑戰。


          4. 如何做分離

          4.1 職責分離


          職責分離

          前后端僅僅通過異步接口(AJAX/JSONP)來編程

          前后端都各自有自己的開發流程,構建工具,測試集合

          關注點分離,前后端變得相對獨立并松耦合

          后端 前端
          提供數據 接收數據,返回數據
          處理業務邏輯 處理渲染邏輯
          Server-side MVC架構 Client-side MV* 架構
          代碼跑在服務器上 代碼跑在瀏覽器上

          4.2 開發流程

          后端編寫和維護接口文檔,在 API 變化時更新接口文檔

          后端根據接口文檔進行接口開發

          前端根據接口文檔進行開發 + Mock平臺

          開發完成后聯調和提交測試

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


          開發流程

          4.3 具體實施

          現在已基本完成了,接口方面的實施:

          接口文檔服務器:可實現接口變更實時同步給前端展示;

          Mock接口數據平臺:可實現接口變更實時Mock數據給前端使用;

          接口規范定義:很重要,接口定義的好壞直接影響到前端的工作量和實現邏輯;具體定義規范見下節;


          接口文檔+Mock平臺服務器


          5. 接口規范V1.0.0

          5.1 規范原則

          接口返回數據即顯示:前端僅做渲染邏輯處理;

          渲染邏輯禁止跨多個接口調用;

          前端關注交互、渲染邏輯,盡量避免業務邏輯處理的出現;

          請求響應傳輸數據格式:JSON,JSON數據盡量簡單輕量,避免多級JSON的出現;

          5.2 基本格式

          5.2.1 請求基本格式

          GET請求、POST請求==必須包含key為body的入參,所有請求數據包裝為JSON格式,并存放到入參body中==,示例如下:

          GET請求:

          xxx/login?body={"username":"admin","password":"123456","captcha":"scfd","rememberMe":1}

          POST請求:


          POST請求

          5.2.2 響應基本格式

          {
              code: 200,
              data: {
                  message: "success"
              }
          }

          code : 請求處理狀態

          200: 請求處理成功

          500: 請求處理失敗

          401: 請求未認證,跳轉登錄頁

          406: 請求未授權,跳轉未授權提示頁

          data.message: 請求處理消息

          code=200 且 data.message="success": 請求處理成功

          code=200 且 data.message!="success": 請求處理成功, 普通消息提示:message內容

          code=500: 請求處理失敗,警告消息提示:message內容

          5.3 響應實體格式

          {
              code: 200,
              data: {
                  message: "success",
                  entity: {
                      id: 1,
                      name: "XXX",
                      code: "XXX"
                  }
              }
          }

          data.entity: 響應返回的實體數據

          5.4 響應列表格式

          {
              code: 200,
              data: {
                  message: "success",
                  list: [
                      {
                          id: 1,
                          name: "XXX",
                          code: "XXX"
                      },
                      {
                          id: 2,
                          name: "XXX",
                          code: "XXX"
                      }
                  ]
              }
          }

          data.list: 響應返回的列表數據

          5.5 響應分頁格式

          {
              code: 200,
              data: {
                  recordCount: 2,
                  message: "success",
                  totalCount: 2,
                  pageNo: 1,
                  pageSize: 10,
                  list: [
                      {
                          id: 1,
                          name: "XXX",
                          code: "H001"
                      },
                      {
                          id: 2,
                          name: "XXX",
                          code: "H001"
                      } ],
                  totalPage: 1
              }
          }

          data.recordCount: 當前頁記錄數
          data.totalCount: 總記錄數
          data.pageNo: 當前頁碼
          data.pageSize: 每頁大小
          data.totalPage: 總頁數

          5.6 特殊內容規范

          5.6.1 下拉框、復選框、單選框

          由后端接口統一邏輯判定是否選中,通過isSelect標示是否選中,示例如下:

          {
              code: 200,
              data: {
                  message: "success",
                  list: [{
                      id: 1,
                      name: "XXX",
                      code: "XXX",
                      isSelect: 1
                  }, {
                      id: 1,
                      name: "XXX",
                      code: "XXX",
                      isSelect: 0
                  }]
              }
          }

          禁止下拉框、復選框、單選框判定選中邏輯由前端來處理,統一由后端邏輯判定選中返回給前端展示;

          5.6.2 Boolean類型

          關于Boolean類型,JSON數據傳輸中一律使用1/0來標示,1為是/True,0為否/False;

          5.6.3 日期類型

          關于日期類型,JSON數據傳輸中一律使用字符串,具體日期格式因業務而定;


          6. 未來的大前端

          目前我們現在用的前后端分離模式屬于第一階段,由于使用到的一些技術jquery等,對于一些頁面展示、數據渲染還是比較復雜,不能夠很好的達到復用。對于前端還是有很大的工作量。

          下一階段可以在前端工程化方面,對技術框架的選擇、前端模塊化重用方面,可多做考量。也就是要迎來“==前端為主的 MV* 時代==”。 大多數的公司也基本都處于這個分離階段。

          最后階段就是==Node 帶來的全棧時代==,完全有前端來控制頁面,URL,Controller,路由等,后端的應用就逐步弱化為真正的數據服務+業務服務,做且僅能做的是提供數據、處理業務邏輯,關注高可用、高并發等。


          來源:http://www.jianshu.com/p/c81008b68350?from=timeline

          站長推薦

          1.阿里云: 本站目前使用的是阿里云主機,安全/可靠/穩定。點擊領取2000元代金券、了解最新阿里云產品的各種優惠活動點擊進入

          2.騰訊云: 提供云服務器、云數據庫、云存儲、視頻與CDN、域名等服務。騰訊云各類產品的最新活動,優惠券領取點擊進入

          3.廣告聯盟: 整理了目前主流的廣告聯盟平臺,如果你有流量,可以作為參考選擇適合你的平臺點擊進入

          鏈接: http://www.modern-decoration.com.cn/article/detial/227

          前端之CSS編碼規范

          那為什么變量名不用小寫字母加小劃線的方式,如:family_tree,而是推薦用駝峰式的familyTree?C語言就喜歡用這種方式命名變量,但是由于因為下劃線比較難敲(shift + -),所以一般用駝峰式命名變量的居多。

          你可能不知道的CSS

          也許有人會說,都快 2019 年了怎么還讀 CSS2.1 規范。一方面,現在最新的 CSS (core) 規范是 CSS2.2,因為 CSS2.1 有中文的版本,并且和 CSS2.2 規范差異性不是很大,基于偷懶的目的最終選擇閱讀了 CSS2.1 規范。

          Js ES6編碼規范

          本章節討論使用ES6編碼風格到代碼中需要注意的點。通過記住這些關鍵點,可以讓我們寫出更優美的、可讀性更強的JavaScript E6風格的代碼。ES6 提出了兩個新的聲明變量的命令: let 和 const。

          分享一份大佬的MySQL數據庫設計規范,值得收藏

          MySQL數據庫與 Oracle、 SQL Server 等數據庫相比,有其內核上的優勢與劣勢。我們在使用MySQL數據庫的時候需要遵循一定規范,揚長避短。無意中從github上看到一個大佬的MySQL數據庫設計規范

          CSS的BEM規范學習

          塊中的子元素是塊的子元素,并且子元素的子元素在 bem 里也被認為是塊的直接子元素。一個塊中元素的類名必須用父級塊的名稱作為前綴。如上面的例子,li.item 是列表的一個子元素

          Web前端開發規范手冊

          文件命名規則:文件名稱統一用小寫的英文字母、數字和下劃線的組合。引文件統一使用index.htm index.html index.asp文件名(小寫),圖片的名稱分為頭尾兩部分,用下劃線隔開,頭部分表示此圖片的大類性質

          為什么有的編程規范要求用 void 0 代替 undefined?

          Undefined 類型表示未定義,它的類型只有一個值,就是 undefined。任何變量在被賦值前它的值都是 undefined,但是在 JavaScript 引擎中,undefined 是一個變量而非關鍵字。

          CSS的書寫規范和順序

          關于CSS的書寫規范和順序,是大部分前端er都必須要攻克的一門關卡,如果沒有按照良好的CSS書寫規范來寫CSS代碼,會影響代碼的閱讀體驗。這里總結了一個CSS書寫規范、CSS書寫順序供大家參考

          實際項目中用Redis要注意哪些規范?

          Redis功能強大,數據類型豐富,再快的系統,也經不住瘋狂的濫用。通過禁用部分高風險功能,并掛上開發的枷鎖,業務更能夠以簡潔、通用的思想去考慮問題,而不是綁定在某種實現上。

          前端標準規范

          總體原則:極簡、極快、解耦,主要適用范圍:vue 單頁項目+;關于圖片:少量直接放到本頁面文件下(資源集中,互不影響),有兩個頁面以上公用則抽離放到 img 文件夾下(降低層級),assets 下的 img 主要放 favicon.png、pwa等全局圖片

          內容以共享、參考、研究為目的,不存在任何商業目的。其版權屬原作者所有,如有侵權或違規,請與小編聯系!情況屬實本人將予以刪除!

          文章投稿關于web前端網站點搜索站長推薦網站地圖站長QQ:522607023

          小程序專欄: 土味情話心理測試腦筋急轉彎幽默笑話段子句子語錄成語大全運營推廣

          国产精品高清视频免费 - 视频 - 在线观看 - 影视资讯 - 唯爱网