av激情亚洲男人的天堂国语,日韩欧美精品一中文字幕,无码av一区二区三区无码,国产又色又爽又刺激的a片,国产又色又爽又刺激的a片

談?wù)勄昂蠓蛛x接口規(guī)范

1. 前言

創(chuàng)新互聯(lián)長期為千余家客戶提供的網(wǎng)站建設(shè)服務(wù)，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為青原企業(yè)提供專業(yè)的做網(wǎng)站、成都網(wǎng)站建設(shè)，青原網(wǎng)站改版等技術(shù)服務(wù)。擁有十余年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

隨著互聯(lián)網(wǎng)的高速發(fā)展，前端頁面的展示、交互體驗越來越靈活、炫麗，響應(yīng)體驗也要求越來越高，后端服務(wù)的高并發(fā)、高可用、高性能、高擴展等特性的要求也愈加苛刻，從而導(dǎo)致前后端研發(fā)各自專注于自己擅長的領(lǐng)域深耕細作。

然而帶來的另一個問題：前后端的對接界面雙方卻關(guān)注甚少，沒有任何接口約定規(guī)范情況下各自干，導(dǎo)致我們在產(chǎn)品項目開發(fā)過程中，前后端的接口聯(lián)調(diào)對接工作量占比在30%-50%左右，甚至?xí)?。往往前后端接口?lián)調(diào)對接及系統(tǒng)間的聯(lián)調(diào)對接都是整個產(chǎn)品項目研發(fā)的軟肋。

本文的主要初衷就是規(guī)范約定先行，盡量避免溝通聯(lián)調(diào)產(chǎn)生的不必要的問題，讓大家身心愉快地專注于各自擅長的領(lǐng)域。

2. 為何要分離

目前現(xiàn)有前后端開發(fā)模式：“后端為主的MVC時代”，如下圖所示：

后端為主的MVC時代

代碼可維護性得到明顯好轉(zhuǎn)，MVC 是個非常好的協(xié)作模式，從架構(gòu)層面讓開發(fā)者懂得什么代碼應(yīng)該寫在什么地方。為了讓 View 層更簡單干脆，還可以選擇 Velocity、Freemaker 等模板，使得模板里寫不了 Java 代碼?？雌饋硎枪δ茏?nèi)趿?，但正是這種限制使得前后端分工更清晰。然而依舊并不是那么清晰，這個階段的典型問題是：

  • 前端開發(fā)重度依賴開發(fā)環(huán)境，開發(fā)效率低。這種架構(gòu)下，前后端協(xié)作有兩種模式：一種是前端寫demo，寫好后，讓后端去套模板 。淘寶早期包括現(xiàn)在依舊有大量業(yè)務(wù)線是這種模式。好處很明顯，demo 可以本地開發(fā)，很高效。不足是還需要后端套模板，有可能套錯，套完后還需要前端確定，來回溝通調(diào)整的成本比較大。另一種協(xié)作模式是前端負責(zé)瀏覽器端的所有開發(fā)和服務(wù)器端的 View 層模板開發(fā)，支付寶是這種模式。好處是 UI 相關(guān)的代碼都是前端去寫就好，后端不用太關(guān)注，不足就是前端開發(fā)重度綁定后端環(huán)境，環(huán)境成為影響前端開發(fā)效率的重要因素。
  • 前后端職責(zé)依舊糾纏不清。Velocity 模板還是蠻強大的，變量、邏輯、宏等特性，依舊可以通過拿到的上下文變量來實現(xiàn)各種業(yè)務(wù)邏輯。這樣，只要前端弱勢一點，往往就會被后端要求在模板層寫出不少業(yè)務(wù)代碼。還有一個很大的灰色地帶是 Controller，頁面路由等功能本應(yīng)該是前端最關(guān)注的，但卻是由后端來實現(xiàn)。Controller 本身與 Model 往往也會糾纏不清，看了讓人咬牙的業(yè)務(wù)代碼經(jīng)常會出現(xiàn)在 Controller 層。這些問題不能全歸結(jié)于程序員的素養(yǎng)，否則 JSP 就夠了。
  • 對前端發(fā)揮的局限。性能優(yōu)化如果只在前端做空間非常有限，于是我們經(jīng)常需要后端合作才能碰撞出火花，但由于后端框架限制，我們很難使用Comet、Bigpipe等技術(shù)方案來優(yōu)化性能。

綜上所述，就跟為什麼要代碼重構(gòu)一樣：

  • 關(guān)注點分離
  • 職責(zé)分離
  • 對的人做對的事
  • 更好的共建模式
  • 快速的反應(yīng)變化

3. 什么是分離

我們現(xiàn)在要做的前后分離第一階段：“基于 Ajax 帶來的 SPA 時代”，如圖：

基于 Ajax 帶來的 SPA 時代

這種模式下，前后端的分工非常清晰，前后端的關(guān)鍵協(xié)作點是 Ajax 接口?？雌饋硎侨绱嗣烂睿剡^頭來看看的話，這與 JSP 時代區(qū)別不大。復(fù)雜度從服務(wù)端的 JSP 里移到了瀏覽器的 JavaScript，瀏覽器端變得很復(fù)雜。類似 Spring MVC，這個時代開始出現(xiàn)瀏覽器端的分層架構(gòu)：[[271096]]

瀏覽器端的分層架構(gòu)

對于這一SPA階段，前后端分離有幾個重要挑戰(zhàn)：

  • 前后端接口的約定。如果后端的接口一塌糊涂，如果后端的業(yè)務(wù)模型不夠穩(wěn)定，那么前端開發(fā)會很痛苦。這一塊在業(yè)界有 API Blueprint 等方案來約定和沉淀接口，==在阿里，不少團隊也有類似嘗試，通過接口規(guī)則、接口平臺等方式來做。有了和后端一起沉淀的接口規(guī)則，還可以用來模擬數(shù)據(jù)，使得前后端可以在約定接口后實現(xiàn)高效并行開發(fā)。== 相信這一塊會越做越好。
  • 前端開發(fā)的復(fù)雜度控制。SPA 應(yīng)用大多以功能交互型為主，JavaScript 代碼過十萬行很正常。大量 JS 代碼的組織，與 View 層的綁定等，都不是容易的事情。典型的解決方案是業(yè)界的 Backbone，但 Backbone 做的事還很有限，依舊存在大量空白區(qū)域需要挑戰(zhàn)。

4. 如何做分離

4.1 職責(zé)分離

職責(zé)分離

  • 前后端僅僅通過異步接口(AJAX/JSONP)來編程
  • 前后端都各自有自己的開發(fā)流程，構(gòu)建工具，測試集合
  • 關(guān)注點分離，前后端變得相對獨立并松耦合

后端前端提供數(shù)據(jù)接收數(shù)據(jù)，返回數(shù)據(jù)處理業(yè)務(wù)邏輯處理渲染邏輯Server-side MVC架構(gòu)Client-side MV* 架構(gòu)代碼跑在服務(wù)器上代碼跑在瀏覽器上

4.2 開發(fā)流程

  • 后端編寫和維護接口文檔，在 API 變化時更新接口文檔
  • 后端根據(jù)接口文檔進行接口開發(fā)
  • 前端根據(jù)接口文檔進行開發(fā) + Mock平臺
  • 開發(fā)完成后聯(lián)調(diào)和提交測試

Mock 服務(wù)器根據(jù)接口文檔自動生成 Mock 數(shù)據(jù)，實現(xiàn)了接口文檔即API：

開發(fā)流程

4.3 具體實施

現(xiàn)在已基本完成了，接口方面的實施：

接口文檔服務(wù)器：可實現(xiàn)接口變更實時同步給前端展示;

Mock接口數(shù)據(jù)平臺：可實現(xiàn)接口變更實時Mock數(shù)據(jù)給前端使用;

接口規(guī)范定義：很重要，接口定義的好壞直接影響到前端的工作量和實現(xiàn)邏輯;具體定義規(guī)范見下節(jié);

接口文檔+Mock平臺服務(wù)器

5. 接口規(guī)范V1.0.0

5.1 規(guī)范原則

接口返回數(shù)據(jù)即顯示：前端僅做渲染邏輯處理;

渲染邏輯禁止跨多個接口調(diào)用;

前端關(guān)注交互、渲染邏輯，盡量避免業(yè)務(wù)邏輯處理的出現(xiàn);

請求響應(yīng)傳輸數(shù)據(jù)格式：JSON，JSON數(shù)據(jù)盡量簡單輕量，避免多級JSON的出現(xiàn);

5.2 基本格式

5.2.1 請求基本格式

GET請求、POST請求==必須包含key為body的入?yún)?，所有請求?shù)據(jù)包裝為JSON格式，并存放到入?yún)ody中==，示例如下：

1.GET請求：

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

2.POST請求：

POST請求

5.2.2 響應(yīng)基本格式

 
 
 
 
    
  
  
  
  
  1. { 
    2.   
  
  
  
  2.  code: 200, 
    3.   
  
  
  
  3.  data: { 
    4.   
  
  
  
  4.  message: "success" 
    5.   
  
  
  
  5.  } 
    6.   
  
  
  
  6. } 
    7.

1.code : 請求處理狀態(tài)

 
 
 
 
    
  
  
  
  
  1. 200: 請求處理成功 500: 請求處理失敗 401: 請求未認證，跳轉(zhuǎn)登錄頁 406: 請求未授權(quán)，跳轉(zhuǎn)未授權(quán)提示頁 
    2.

2.data.message: 請求處理消息

 
 
 
 
    
  
  
  
  
  1. code=200 且 data.message="success": 請求處理成功 code=200 且 data.message!="success": 請求處理成功, 普通消息提示：message內(nèi)容 code=500: 請求處理失敗，警告消息提示：message內(nèi)容 
    2.

5.3 響應(yīng)實體格式

 
 
 
 
    
  
  
  
  
  1. { 
    2.   
  
  
  
  2.  code: 200, 
    3.   
  
  
  
  3.  data: { 
    4.   
  
  
  
  4.  message: "success", 
    5.   
  
  
  
  5.  entity: { 
    6.   
  
  
  
  6.  id: 1, 
    7.   
  
  
  
  7.  name: "XXX", 
    8.   
  
  
  
  8.  code: "XXX" 
    9.   
  
  
  
  9.  } 
    10.   
  
  
  
  10.  } 
    11.   
  
  
  
  11. } 
    12.

data.entity: 響應(yīng)返回的實體數(shù)據(jù)

5.4 響應(yīng)列表格式

 
 
 
 
    
  
  
  
  
  1. { 
    2.   
  
  
  
  2.  code: 200, 
    3.   
  
  
  
  3.  data: { 
    4.   
  
  
  
  4.  message: "success", 
    5.   
  
  
  
  5.  list: [ 
    6.   
  
  
  
  6.  { 
    7.   
  
  
  
  7.  id: 1, 
    8.   
  
  
  
  8.  name: "XXX", 
    9.   
  
  
  
  9.  code: "XXX" 
    10.   
  
  
  
  10.  }, 
    11.   
  
  
  
  11.  { 
    12.   
  
  
  
  12.  id: 2, 
    13.   
  
  
  
  13.  name: "XXX", 
    14.   
  
  
  
  14.  code: "XXX" 
    15.   
  
  
  
  15.  } 
    16.   
  
  
  
  16.  ] 
    17.   
  
  
  
  17.  } 
    18.   
  
  
  
  18. } 
    19.

data.list: 響應(yīng)返回的列表數(shù)據(jù)

5.5 響應(yīng)分頁格式

 
 
 
 
    
  
  
  
  
  1. { 
    2.   
  
  
  
  2.  code: 200, 
    3.   
  
  
  
  3.  data: { 
    4.   
  
  
  
  4.  recordCount: 2, 
    5.   
  
  
  
  5.  message: "success", 
    6.   
  
  
  
  6.  totalCount: 2, 
    7.   
  
  
  
  7.  pageNo: 1, 
    8.   
  
  
  
  8.  pageSize: 10, 
    9.   
  
  
  
  9.  list: [ 
    10.   
  
  
  
  10.  { 
    11.   
  
  
  
  11.  id: 1, 
    12.   
  
  
  
  12.  name: "XXX", 
    13.   
  
  
  
  13.  code: "H001" 
    14.   
  
  
  
  14.  }, 
    15.   
  
  
  
  15.  { 
    16.   
  
  
  
  16.  id: 2, 
    17.   
  
  
  
  17.  name: "XXX", 
    18.   
  
  
  
  18.  code: "H001" 
    19.   
  
  
  
  19.  } ], 
    20.   
  
  
  
  20.  totalPage: 1 
    21.   
  
  
  
  21.  } 
    22.   
  
  
  
  22. } 
    23.

data.recordCount: 當(dāng)前頁記錄數(shù) data.totalCount: 總記錄數(shù) data.pageNo: 當(dāng)前頁碼 data.pageSize: 每頁大小 data.totalPage: 總頁數(shù)

5.6 特殊內(nèi)容規(guī)范

5.6.1 下拉框、復(fù)選框、單選框

由后端接口統(tǒng)一邏輯判定是否選中，通過isSelect標示是否選中，示例如下：

 
 
 
 
    
  
  
  
  
  1. { 
    2.   
  
  
  
  2.  code: 200, 
    3.   
  
  
  
  3.  data: { 
    4.   
  
  
  
  4.  message: "success", 
    5.   
  
  
  
  5.  list: [{ 
    6.   
  
  
  
  6.  id: 1, 
    7.   
  
  
  
  7.  name: "XXX", 
    8.   
  
  
  
  8.  code: "XXX", 
    9.   
  
  
  
  9.  isSelect: 1 
    10.   
  
  
  
  10.  }, { 
    11.   
  
  
  
  11.  id: 1, 
    12.   
  
  
  
  12.  name: "XXX", 
    13.   
  
  
  
  13.  code: "XXX", 
    14.   
  
  
  
  14.  isSelect: 0 
    15.   
  
  
  
  15.  }] 
    16.   
  
  
  
  16.  } 
    17.   
  
  
  
  17. } 
    18.

禁止下拉框、復(fù)選框、單選框判定選中邏輯由前端來處理，統(tǒng)一由后端邏輯判定選中返回給前端展示;

5.6.2 Boolean類型

關(guān)于Boolean類型，JSON數(shù)據(jù)傳輸中一律使用1/0來標示，1為是/True，0為否/False;

5.6.3 日期類型

關(guān)于日期類型，JSON數(shù)據(jù)傳輸中一律使用字符串，具體日期格式因業(yè)務(wù)而定;

6. 未來的大前端

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

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

最后階段就是==Node 帶來的全棧時代==，完全有前端來控制頁面，URL，Controller，路由等，后端的應(yīng)用就逐步弱化為真正的數(shù)據(jù)服務(wù)+業(yè)務(wù)服務(wù)，做且僅能做的是提供數(shù)據(jù)、處理業(yè)務(wù)邏輯，關(guān)注高可用、高并發(fā)等。


本文名稱：談?wù)勄昂蠓蛛x接口規(guī)范
路徑分享：http://uogjgqi.cn/article/cdcjgci.html
掃二維碼與項目經(jīng)理溝通

我們在微信上24小時期待你的聲音

解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流