摘要：針對(duì)上面看到的問(wèn)題，現(xiàn)在也有一些團(tuán)隊(duì)在嘗試前后端之間加一個(gè)中間層比如淘寶的。淘寶有很多類似的文章，這里不贅述。淘寶團(tuán)隊(duì)做了兩套接口文檔的維護(hù)工具，以及，不知道有沒(méi)有對(duì)外開(kāi)放，兩個(gè)東西都是基于的一個(gè)嘗試，各有優(yōu)劣。

原文出處： 小胡子哥的博客（@Barret李靖）

前后端分工協(xié)作是一個(gè)老生常談的大話題，很多公司都在嘗試用工程化的方式去提升前后端之間交流的效率，降低溝通成本，并且也開(kāi)發(fā)了大量的工具。但是幾乎沒(méi)有一種方式是令雙方都很滿意的。事實(shí)上，也不可能讓所有人都滿意。根本原因還是前后端之間的交集不夠大，交流的核心往往只限于接口及接口往外擴(kuò)散的一部分。這也是為什么很多公司在招聘的時(shí)候希望前端人員熟練掌握一門后臺(tái)語(yǔ)言，后端同學(xué)了解前端的相關(guān)知識(shí)。

一、開(kāi)發(fā)流程

前端切完圖，處理好接口信息，接著就是把靜態(tài)demo交給后臺(tái)去拼接，這是一般的流程。這種流程存在很多的缺陷。

后端同學(xué)對(duì)文件進(jìn)行拆分拼接的時(shí)候，由于對(duì)前端知識(shí)不熟悉，可能會(huì)搞出一堆bug，到最后又需要前端同學(xué)幫助分析原因，而前端同學(xué)又不是特別了解后端使用的模板，造成尷尬的局面。

如果前端沒(méi)有使用統(tǒng)一化的文件夾結(jié)構(gòu)，并且靜態(tài)資源（如圖片，css，js等）沒(méi)有剝離出來(lái)放到 CDN，而是使用相對(duì)路徑去引用，當(dāng)后端同學(xué)需要對(duì)靜態(tài)資源作相關(guān)配置時(shí)，又得修改各個(gè)link，script標(biāo)簽的src屬性，容易出錯(cuò)。

接口問(wèn)題
后端數(shù)據(jù)沒(méi)有準(zhǔn)備好，前端需要自己模擬一套，成本高，如果后期接口有改變，自己模擬的那套數(shù)據(jù)又不行了。

后端數(shù)據(jù)已經(jīng)開(kāi)發(fā)好，接口也準(zhǔn)備好了，本地需要代理線上數(shù)據(jù)進(jìn)行測(cè)試。這里有兩個(gè)費(fèi)神的地方，一是需要代理，否則可能跨域，二是接口信息如果改動(dòng)，后期接你項(xiàng)目的人需要改你的代碼，麻煩。

不方便控制輸出。為了讓首屏加載速度快一點(diǎn)，我們期望后端先吐出一點(diǎn)數(shù)據(jù)，剩下的才去 ajax 渲染，但讓后端吐出多少數(shù)據(jù)，我們不好控。

當(dāng)然，存在的問(wèn)題遠(yuǎn)不止上面枚舉的這些，這種傳統(tǒng)的方式實(shí)在是不酷（Kimi 附身^_^）。還有一種開(kāi)發(fā)流程，SPA（single page application），前后端職責(zé)相當(dāng)清晰，后端給我接口，我全部用 ajax 異步請(qǐng)求，這種方式，在現(xiàn)代瀏覽器中可以使用 PJAX 稍微提高體驗(yàn)，F(xiàn)acebook 早在三四年前對(duì)這種 SPA 的模式提出了一套解決方案，quickling+bigpipe，解決了 SEO 以及數(shù)據(jù)吐出過(guò)慢的問(wèn)題。他的缺點(diǎn)也是十分明顯的：

頁(yè)面太重，前端渲染工作量也大
首屏還是慢
前后端模板復(fù)用不了
SEO 依然很狗血（quickling 架構(gòu)成本高）
history 管理麻煩
問(wèn)題多的已經(jīng)是無(wú)力吐槽了，當(dāng)然他依然有自己的優(yōu)勢(shì)，咱們也不能一票否決。

針對(duì)上面看到的問(wèn)題，現(xiàn)在也有一些團(tuán)隊(duì)在嘗試前后端之間加一個(gè)中間層（比如淘寶UED的 MidWay ）。這個(gè)中間層由前端來(lái)控制。

JavaScript

+----------------+
|       F2E      |
+---↑--------↑---+
    |        | 
+---↓--------↓---+
|     Middle     |
+---↑--------↑---+
    |        |  
+---↓--------↓---+
|       R2E      |
+----------------+

+----------------+
|       F2E      |
+---↑--------↑---+
    |        | 
+---↓--------↓---+
|     Middle     |
+---↑--------↑---+
    |        |  
+---↓--------↓---+
|       R2E      |
+----------------+

中間層的作用就是為了更好的控制數(shù)據(jù)的輸出，如果用MVC模型去分析這個(gè)接口，R2E（后端）只負(fù)責(zé) M（數(shù)據(jù)） 這部分，Middle（中間層）處理數(shù)據(jù)的呈現(xiàn)（包括 V 和 C）。淘寶UED有很多類似的文章，這里不贅述。

二、核心問(wèn)題

上面提出了在業(yè)務(wù)中看到的常見(jiàn)的三種模式，問(wèn)題的核心就是數(shù)據(jù)交給誰(shuí)去處理。數(shù)據(jù)交給后臺(tái)處理，這是模式一，數(shù)據(jù)交給前端處理，這是模式二，數(shù)據(jù)交給前端分層處理，這是模式三。三種模式?jīng)]有優(yōu)劣之分，其使用還是得看具體場(chǎng)景。

既然都是數(shù)據(jù)的問(wèn)題，數(shù)據(jù)從哪里來(lái)？這個(gè)問(wèn)題又回到了接口。

接口文檔由誰(shuí)來(lái)撰寫和維護(hù)？
接口信息的改動(dòng)如何向前后端傳遞？
如何根據(jù)接口規(guī)范拿到前后端可用的測(cè)試數(shù)據(jù)？
使用哪種接口？JSON，JSONP？
JSONP 的安全性問(wèn)題如何處理？
這一系列的問(wèn)題一直困擾著奮戰(zhàn)在前線的前端工程師和后端開(kāi)發(fā)者。淘寶團(tuán)隊(duì)做了兩套接口文檔的維護(hù)工具，IMS以及DIP，不知道有沒(méi)有對(duì)外開(kāi)放，兩個(gè)東西都是基于 JSON Schema 的一個(gè)嘗試，各有優(yōu)劣。JSON Schema 是對(duì) JSON 的一個(gè)規(guī)范，類似我們?cè)跀?shù)據(jù)庫(kù)中創(chuàng)建表一樣，對(duì)每個(gè)字段做一些限制，這里也是一樣的原理，可以對(duì)字段進(jìn)行描述，設(shè)置類型，限制字段屬性等。

接口文檔這個(gè)事情，使用 JSON Schema 可以自動(dòng)化生產(chǎn)，所以只需編寫 JSON Schema 而不存在維護(hù)問(wèn)題，在寫好的 Schema 中多加些限制性的參數(shù)，我們就可以直接根據(jù) Schema 生成 mock（測(cè)試） 數(shù)據(jù)。

mock 數(shù)據(jù)的外部調(diào)用，這倒是很好處理：

JavaScript

typeof callback === "function" && callback({
   json: "jsonContent"
})

typeof callback === "function" && callback({
   json: "jsonContent"
})

在請(qǐng)求的參數(shù)中加入 callback 參數(shù)，如 /mock/hashString?cb=callback，一般的 io(ajax) 庫(kù)都對(duì)異步數(shù)據(jù)獲取做了封裝，我們?cè)跍y(cè)試的時(shí)候使用 jsonp，回頭上線，將 dataType 改成 json 就行了。

JavaScript

IO({
  url: "http://barretlee.com",
  dataType: "jsonp", //json
  success: function(){}
})

IO({
  url: "http://barretlee.com",
  dataType: "jsonp", //json
  success: function(){}
})

這里略微麻煩的是 POST 方法，jsonp 只能使用 get 方式插入 script 節(jié)點(diǎn)去請(qǐng)求數(shù)據(jù)，但是 POST，只能呵呵了。

這里的處理也有多重方式可以參考：

修改 Hosts，讓 mock 的域名指向開(kāi)發(fā)域名
mock 設(shè)置 header 響應(yīng)頭，Access-Allow-Origin-Control
對(duì)于如何拿到跨域的接口信息，我也給出幾個(gè)參考方案：

fiddler 替換包，好像是支持正則的，感興趣的可以研究下（求分享研究結(jié)果，因?yàn)槲覜](méi)找到正則的設(shè)置位置）
使用 HTTPX 或者其他代理工具，原理和 fiddler 類似，不過(guò)可視化效果（體驗(yàn)）要好很多，畢竟人家是專門做代理用的。
自己寫一段腳本代理，也就是本地開(kāi)一個(gè)代理服務(wù)器，這里需要考慮端口的占用問(wèn)題。其實(shí)我不推薦監(jiān)聽(tīng)端口，一個(gè)比較不錯(cuò)的方案是本地請(qǐng)求全部指向一個(gè)腳本文件，然后腳本轉(zhuǎn)發(fā)URL，如：
JavaScript

原始請(qǐng)求：http://barretlee.com/api/test...
在ajax請(qǐng)求的時(shí)候：

$.ajax({
  url: "http:///api.php?path=/api/text.json"
});

原始請(qǐng)求：http://barretlee.com/api/test.json
在ajax請(qǐng)求的時(shí)候：
$.ajax({
  url: "http:///api.php?path=/api/text.json"
});
php中處理就比較簡(jiǎn)單啦：
JavaScript

if(!isset($_GET["page"])){
  echo 0;
  exit();
}
echo file_get_contents($_GET["path"]);

if(!isset($_GET["page"])){
  echo 0;
  exit();
}
echo file_get_contents($_GET["path"]);

Ctrl+S,保存把線上的接口數(shù)據(jù)到本地的api文件夾吧-_-||
三、小結(jié)

本文只是對(duì)前后端協(xié)作存在的問(wèn)題和現(xiàn)有的幾種常見(jiàn)模式做了簡(jiǎn)要的列舉，JSON Schema 具體如何去運(yùn)用，還有接口的維護(hù)問(wèn)題、接口信息的獲取問(wèn)題沒(méi)有具體闡述，這個(gè)后續(xù)有時(shí)間會(huì)整理下我對(duì)他的理解。